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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
