Can DOM methods be native Function objects?
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.
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.
On 10/10/10, Brendan Eich <brendan at mozilla.com> 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 <brendan at 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.
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:
On 10/10/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
On 10/10/10, Brendan Eich <brendan at mozilla.com> wrote:
On Oct 10, 2010, at 4:14 PM, Mark S. Miller wrote: [...]
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
No! I wrote the opposite of what I really meant. I always considered them to be host objects, not built-ins. Sorry!
"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).
Right; that's what I meant. [...]
On Oct 10, 2010, at 8:54 PM, Garrett Smith wrote:
On 10/10/10, Brendan Eich <brendan at mozilla.com> 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.)
Lighten up! First, I wrote "If" in "If the spec says otherwise, the spec is an ass, to borrow from Dickens." Second, the Dickens in question is Oliver Twist, see www.texasbar.com/saywhat/weblog/buchmeyer_article_archive/may84.asp. Too much "judicial reasoning" about specs trumping more humorous reality (the ES standard is Mr. Bumble, the DOM standard is his wife; wait, no... :-P).
If a host method obeys that contract, how could one determine if it were not a native function?
Some people read the spec to define any such method as a host (callable) object of some kind, never a native function.
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.
(A VBScript-ism, not being standardized in WebIDL.)
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?
The belief that keeps recurring on this list, most recently in Cameron's post, that the specs forbid DOM methods from being native function objects. Cameron's second bulleted "Which one of the following is true?" answer was
- a custom [[Call]] is needed, but native objects are allowed to have a custom [[Call]]; or
is the right answer but it is not obvious from ES5 that this is allowed for "host objects" not defined by the spec. It's a subtle point that we should clarify so we don't have to around this block again.
It is really a terrible shame this is all so confusing. Part of the problem is terminology wrongly suggesting other meanings. "host" simply means "non-native".
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.
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.
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.
On Mon, Oct 11, 2010 at 5:54 AM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:
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?
If the "one" in your question is the JS programmer, one determines by testing if its [[Class]] is "Function".
I think maybe if you want to say that host methods should be just specified as functions, where that makes sense.
Need to be careful with terms to avoid confusion here. We're talking about methods of host objects. If we're already talking about a host method, then the matter is decided. If it is a host method, then presumably it is a host object, and so it is by definition not a function.
Substituting "method of host object" above, I agree. But as a normative issue, this currently falls in the gap between w3c and ecma.
Because then you know you have a function, and thus a "length" property, [[Call]] property, etc.
y
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)
Link please? IIRC, this part of the conversation was subsequently falsified. "host" and "native" are disjoint. "host" simply means not "native". The first bullet above makes no sense.
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?
Agree with the thought, but again let's keep our terminology straight. If a DOM object is specified to be a native object, then it is a DOM native object, not a DOM host object.
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 15.3.4.5.3 (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.
Thanks,
Cameron
On 10/10/10, Mark S. Miller <erights at google.com> wrote:
It is really a terrible shame this is all so confusing. Part of the problem is terminology wrongly suggesting other meanings. "host" simply means "non-native".
How do you figure? I'm looking at the definition for host object (s 4.3.8) and it doesn't say anything about how a host object is not native.
| 4.3.8 | host object | object supplied by the host environment to complete | the execution environment of ECMAScript.
I interpet that with an omitted "Any", as in:
"Any object supplied by the host environment to complete the execution environment of ECMAScript."
(and I would rather see that sentence thusly changed, provided my interpretation is correct)
NOTE Any object that is not native is a host object.
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.
If by "general contract" you meant the things listed in table 8, then
that is correct. However, that is limited e.g. what happens when a
host object is supplied as the this value to
Array.prototype.slice.
The problem with the language in Array methods (AISI) is that they use "host object" to mean "not native" (your interpretation of "host object"). Should this language be changed? That is, should the wording of "host object" be changed to "not native" where "not native" is intended? That seems clearer to me.
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.
The DOM objects are not defined by ECMAScript, they are defined by other specifications. Any DOM specification may specify an object as being native ECMAScript object (or Function). And when it does that, it can be expected
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.
Such as LiveConnect Java objects.
For purpose of the DOM, yes. Just specify that, e.g. "addEventListener" is a native function and you've thereby subscribed the implementation to obide to that contract.
Language extensions should be banished from WebIDL.
Garrett
On 10/10/10, Garrett Smith <dhtmlkitchen at gmail.com> wrote: [...]
The DOM objects are not defined by ECMAScript, they are defined by other specifications. Any DOM specification may specify an object as being native ECMAScript object (or Function). And when it does that, it can be expected
.. that the object abides by the contract specified in ECMA-262.
(I do that sometimes.)
Mark S. Miller:
It is really a terrible shame this is all so confusing. Part of the problem is terminology wrongly suggesting other meanings. "host" simply means "non-native".
Garrett Smith:
How do you figure? I'm looking at the definition for host object (s 4.3.8) and it doesn't say anything about how a host object is not native.
Indeed, it only says that those objects that aren’t native are host objects, in the NOTE:
NOTE Any object that is not native is a host object.
Is there anything else in the spec that requires objects to be native objects or host objects but not both? If not, and if this (Mark’s) interpretation is meant to be the correct one, then I’d suggest that note be changed in an erratum to say this explicitly.
On 10/10/10, Mark S. Miller <erights at google.com> wrote:
On Mon, Oct 11, 2010 at 5:54 AM, Garrett Smith <dhtmlkitchen at gmail.com>wrote: [...]
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)
Link please? IIRC, this part of the conversation was subsequently falsified. "host" and "native" are disjoint. "host" simply means not "native". The first bullet above makes no sense.
You disagreed with Allen's explanation: www.mail-archive.com/[email protected]/msg04565.html
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.
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 <brendan at 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-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es5-discuss > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101011/9faf301b/attachment.html>