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 function. On Mon, Oct 11, 2010 at 12:41 AM, Brendan Eich <bren...@mozilla.org> 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-disc...@mozilla.org > https://mail.mozilla.org/listinfo/es5-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
