Should host objects be able to have [[Class]] "Function", "RegExp", or "Date"?

David-Sarah Hopwood david.hopwood at
Thu Nov 20 10:44:38 PST 2008

Maciej Stachowiak wrote:
> On Nov 20, 2008, at 1:39 AM, David-Sarah Hopwood wrote:
>> Maciej Stachowiak wrote:
>> But internal functions by that
>> definition are native Function objects, so they are not relevant to
>> the argument about host objects. They only differ from non-internal
>> Function objects by having a [[Call]] method that executes non-ECMAScript
>> code, and by being excluded from the discussion of Execution Contexts in
>> chapter 10.
> If all non-ECMAScript-coded methods in the DOM, or other add-on
> interfaces, can be Native internal functions rather than Host objects,
> even if they have behavior that does not match any predefined native
> Function, [...]

No, if they are native functions then they must match the behaviour of
a function that could have been coded in ECMAScript.

'parseInt', for example, could be coded in pure ECMAScript.
'Math.random' could be coded in ECMAScript if it communicated with a
host object in order to obtain an initial source of entropy.

Host objects, on the other hand, can have almost arbitrary behaviour,
essentially constrained only be the type signatures in the table of
section 8.6.2. That section says:

# For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
# [[Delete]] and [[DefaultValue]] methods behave as described in
# described in,,,, and,
# respectively, except that Array objects have a slightly different
# implementation of the [[Put]] method (see Host objects may
# implement these methods in any manner unless specified otherwise; for
# example, one possibility is that [[Get]] and [[Put]] for a particular
# host object indeed fetch and store property values but [[HasProperty]]
# always generates false.

The first sentence here also constrains internal function objects.

> then I am not sure what a requirement for Host objects not to
> have [[Class]] "Function" would achieve.

For functions, this requirement only simplifies the specification of
the 'bind' method slightly. The more significant problems are with
RegExp and Date -- those sections pervasively assume that anything
with [[Class]] "RegExp" behaves like a native RegExp object, and that
anything with [[Class]] "Date" behaves like a native Date object.

David-Sarah Hopwood

More information about the Es-discuss mailing list