On 10/10/10, Mark S. Miller <erig...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
