On Jan 28, 2012, at 11:33 AM, John-David Dalton wrote: > @Allen > >> > >> Also, the definition of Host Object needs to be tighten up to make it clear >> that an object is only a host object if it has some "magical" behavior. > > -1 magical.
the spec. won't actually say "magical", but the important distinction that the spec. needs to make concerns objects that have special behaviors (ie, different from the "native object" behaviors defined within the specification). It really doesn't matter to the spec if such objects are supplied by the "engine" implementation or a host environment or some "foreign object" interface. The only thing that is important is that they in some way deviate from the definition of native objects. Similar, if an object is not observably different in its behavior from the specification for a native object then it does not matter how it was defined. In the case of ({}}.toString.call(window.opera) the fact that it returns a value that is not in the specification is enough "magic" to qualify window.opera as such a non-native object. >> Finally, window.opera is really just a normal object it could use my >> proposed private name based mechanism to set its toString tag. > > -1 for the more complex option. We want to be able to define things that were historically implemented as "host objects" using pure ECMAScript code. One things such objects have done is to extend the range of values produced by Object.prototype.toString. So, we need a pure ECMAScript way to accomplish that. Allen Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss