On 10/10/10, Brendan Eich <[email protected]> wrote: > On Oct 10, 2010, at 4:14 PM, Mark S. Miller wrote: > >> My interpretation is that the spec in this regard is consistent with >> reality as intended and is not an ass. >
(Somewhat disconcerting to hear hints of the spec being called an ass.) > Could be -- I know we have discussed this before, and I like your > interpretation, but Cameron is only the latest among many to reach different > categorical conclusions, which did not include yours (if I have not misread > his). Something is unclear in the spec. > > /be > >> 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. Well duh! 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". >> Yes, we've discussed this before. >> 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. >> If a host method obeys that contract, how could one determine if it were not a native function? I think maybe if you want to say that host methods should be just specified as functions, where that makes sense. Because then you know you have a function, and thus a "length" property, [[Call]] property, etc. Some implementations have callable host objects that don't need to be functions, e.g. document.images, which in many implementations is callable as "document.images(0)" but is not a function. >> >> On Mon, Oct 11, 2010 at 12:41 AM, Brendan Eich <[email protected]> >> 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. Are the DOM functions considered built-in functions or host methods? Now I always considered them build-ins because "A built-in object is any object supplied by an ECMAScript implementation". AIUI, DOM objects are not defined by the ECMAScript implementation, /though their semantics may be/ (native host object). And that brings me to my next point: AIUI, host objects have two types. We discussed this before... (searching archives...) | The specification allows for two types of host objects: | * host objects as native objects | * host objects as not native objects (does not use | native semantics) and | While the specification does not preclude the possibility that a host | object may be implemented with native semantics, it nonetheless | defines a host object: >From thread "[[Class]] Property of Host Object". 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. >> Any DOM host object specified to be a native ES object can be expected to follow native semantics. What are you hoping to fix? -- Garrett _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
