Can DOM methods be native Function objects?

Mark S. Miller erights at
Sun Oct 10 16:14:44 PDT 2010

My interpretation is that the spec in this regard is consistent with reality
as intended and is not an ass. Native functions can be written in JS or be
built in. The "semantics defined by the spec" does not mean that the spec
says what specifically their internal [[Call]] method does when called. It
does say what the overall contract is. For example, it must inherit from
Function.prototype. It must have an integer length. It must have a [[Call]]
property, and thus its "typeof" must be "function". And it should have a
[[Class]] of "Function".

In other words, [[Class]] "Function" is one of the native internal nominal
types whose contract is defined by the spec. If a method of a host object
obeys that contract, it would be best for it to actually be a native

On Mon, Oct 11, 2010 at 12:41 AM, Brendan Eich <brendan at> wrote:

> On Oct 10, 2010, at 3:28 PM, Brendan Eich wrote:
> > Native functions do not have associated FunctionBody representations, of
> course; one clue is what toString returns.
> Here I use "native functions" to mean either the built-in functions of ES5
> clause 15, or the DOM built-in functions. Although the spec draws a bright
> line around its built-ins vs. "host objects", real implementations use the
> same native-function variant of function objects for both. This is important
> reality to support with some spec fixes.
> What's more, we hope to self-host DOM methods over time, so the WebIDL
> specs should not require built-in or "native" implementation. It should not
> be mandatory. But now I think we are way beyond es5-discuss territory.
> Setting reply-to.
> /be
> _______________________________________________
> es5-discuss mailing list
> es5-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es5-discuss mailing list