Can DOM methods be native Function objects?

Cameron McCormack cam at
Sun Oct 10 22:44:05 PDT 2010

Mark S. Miller:
> The ES5 spec defines a set of internal nominal types-as-contracts,
> identified by their [[Class]] binding. Whether built-in or not, an object
> claiming one of these [[Class]]es must obey the corresponding contract. For
> the specific specified contracts, these objects are "native" objects. The
> spec allows an implementation to provide "host" objects that don't claim to
> satisfy one of these more specific contracts by having a different
> [[Class]]. Such objects may still happen to satisfy one of these more
> specific contracts, but they do not claim to. All objects, host or native,
> must still satisfy the general contract that applies to all ES objects.

What is not clear to me is exactly what the contract is, and this is
where my confusion lies.  The spec says native objects are those “object
in an ECMAScript implementation whose semantics are fully defined by
this specification rather than by the host environment”.  But what does
“semantics” mean here?  13.2.1 seems to give a [[Call]] method
definition for all Function objects, so I interepreted that as being
part of the contract for native functions.  If not, then does
“semantics” just mean that it has a [[Call]] method at all?

Compare this with objects that have a [[HasInstance]] method that
doesn’t do the same thing as that specified in (as Web IDL
currently requires of its so-called “interface objects”, like
[global object].HTMLElement).  Would this result in such an object being
a host object?

> As for whether DOM methods that could, within their specification, claim to
> be native Functions, ES doesn't say whether they should or should not claim
> to be functions. It only says that if they do claim to be functions they
> must actually be functions.

I see that the definition of “function” in 4.3.24 says

  A function’s code may or may not be written in ECMAScript.

Now that’s definitely not compatible with the [[Call]] defined in
13.2.1, since if the code is not written in ECMAScript it likely doesn’t
match FunctionBody, which [[Call]] requires the object’s [[Code]] to.

> Language lawyering aside, my own sense is that all methods that could be
> functions should be functions. We should only specify that an object is
> non-native when we need to.

I hope so.



Cameron McCormack ≝

More information about the es5-discuss mailing list