On Oct 12, 2009, at 12:23 AM, Maciej Stachowiak wrote:
I don't want to get too deep into this, but I question the claim
that it's technically compatible with ES5. Yes, it's possible for a
host object to return any value at any time for a property access.
But for it to consistently decide this based on the context of the
accessing code, this essentially means that ES3 [[Get]] (or the ES5
equivalent) are getting extra parameters that indicate what kind of
expression contains the subexpression.
No, it means the host object can use a back-channel, or telepathy, or
something outside of the specs but definitely inside of the
implementation.
Not every host object observable has to be explainable with fully
parameterized [[Get]] or other internal methods.
Moving to es-discuss with Reply-to: set. The question here is about
ECMA-262.
The bigger picture is this: in order to emulate document.all uses that
assume IE (that are not "detected", e.g. via 'if (document.all)
{...}') we have two divergent implementations:
Mozilla's 2004 implementation uses bytecode introspection to decide
what contexts are "detecting" and the rest are not. Detecting contexts:
if, ?:, switch, {===,!==,==,!=} x {null,undefined}, !, typeof, ||, &&,
assignment including property initialization
WebKit's later document.all implementation which binds that
property to an object that masquerades as undefined:
ToBoolean conversions on the all collection object return false
The all collection object compares equal to null (for purposes of
==, !=).
The all collection object compares equal to undefined (for purposes
of ==, != and not ===, !==).
typeof returns "undefined" for the all collection
I don't want to dig my own deep hole either ;-), but I content (1)
does not violate ECMA-262, while 2 does (since ToBoolean(Object) does
not have a host object exemption, and the "== null/undefined" likewise
does not involve delegating to a host object). A more productive
question is: can we standardize either approach in the relevant
standards bodies' specs? Or is there a third way?
On Oct 12, 2009, at 12:23 AM, Maciej Stachowiak wrote:
> I don't want to get too deep into this, but I question the claim
> that it's technically compatible with ES5. Yes, it's possible for a
> host object to return any value at any time for a property access.
> But for it to consistently decide this based on the context of the
> accessing code, this essentially means that ES3 [[Get]] (or the ES5
> equivalent) are getting extra parameters that indicate what kind of
> expression contains the subexpression.
No, it means the host object can use a back-channel, or telepathy, or
something outside of the specs but definitely inside of the
implementation.
Not every host object observable has to be explainable with fully
parameterized [[Get]] or other internal methods.
Moving to es-discuss with Reply-to: set. The question here is about
ECMA-262.
The bigger picture is this: in order to emulate document.all uses that
assume IE (that are not "detected", e.g. via 'if (document.all)
{...}') we have two divergent implementations:
1. Mozilla's 2004 implementation uses bytecode introspection to decide
what contexts are "detecting" and the rest are not. Detecting contexts:
if, ?:, switch, {===,!==,==,!=} x {null,undefined}, !, typeof, ||, &&,
assignment including property initialization
2. WebKit's later document.all implementation which binds that
property to an object that masquerades as undefined:
- ToBoolean conversions on the all collection object return false
- The all collection object compares equal to null (for purposes of
==, !=).
- The all collection object compares equal to undefined (for purposes
of ==, != and not ===, !==).
- typeof returns "undefined" for the all collection
I don't want to dig my own deep hole either ;-), but I content (1)
does not violate ECMA-262, while 2 does (since ToBoolean(Object) does
not have a host object exemption, and the "== null/undefined" likewise
does not involve delegating to a host object). A more productive
question is: can we standardize either approach in the relevant
standards bodies' specs? Or is there a third way?
/be
On Oct 12, 2009, at 12:23 AM, Maciej Stachowiak wrote:
No, it means the host object can use a back-channel, or telepathy, or
something outside of the specs but definitely inside of the
implementation.
Not every host object observable has to be explainable with fully
parameterized [[Get]] or other internal methods.
Moving to es-discuss with Reply-to: set. The question here is about
ECMA-262.
The bigger picture is this: in order to emulate document.all uses that
assume IE (that are not "detected", e.g. via 'if (document.all)
{...}') we have two divergent implementations:
what contexts are "detecting" and the rest are not. Detecting contexts:
if, ?:, switch, {===,!==,==,!=} x {null,undefined}, !, typeof, ||, &&,
assignment including property initialization
property to an object that masquerades as undefined:
==, !=).
of ==, != and not ===, !==).
I don't want to dig my own deep hole either ;-), but I content (1)
does not violate ECMA-262, while 2 does (since ToBoolean(Object) does
not have a host object exemption, and the "== null/undefined" likewise
does not involve delegating to a host object). A more productive
question is: can we standardize either approach in the relevant
standards bodies' specs? Or is there a third way?
On Oct 12, 2009, at 12:23 AM, Maciej Stachowiak wrote: > I don't want to get too deep into this, but I question the claim > that it's technically compatible with ES5. Yes, it's possible for a > host object to return any value at any time for a property access. > But for it to consistently decide this based on the context of the > accessing code, this essentially means that ES3 [[Get]] (or the ES5 > equivalent) are getting extra parameters that indicate what kind of > expression contains the subexpression. No, it means the host object can use a back-channel, or telepathy, or something outside of the specs but definitely inside of the implementation. Not every host object observable has to be explainable with fully parameterized [[Get]] or other internal methods. Moving to es-discuss with Reply-to: set. The question here is about ECMA-262. The bigger picture is this: in order to emulate document.all uses that assume IE (that are not "detected", e.g. via 'if (document.all) {...}') we have two divergent implementations: 1. Mozilla's 2004 implementation uses bytecode introspection to decide what contexts are "detecting" and the rest are not. Detecting contexts: if, ?:, switch, {===,!==,==,!=} x {null,undefined}, !, typeof, ||, &&, assignment including property initialization 2. WebKit's later document.all implementation which binds that property to an object that masquerades as undefined: - ToBoolean conversions on the all collection object return false - The all collection object compares equal to null (for purposes of ==, !=). - The all collection object compares equal to undefined (for purposes of ==, != and not ===, !==). - typeof returns "undefined" for the all collection I don't want to dig my own deep hole either ;-), but I content (1) does not violate ECMA-262, while 2 does (since ToBoolean(Object) does not have a host object exemption, and the "== null/undefined" likewise does not involve delegating to a host object). A more productive question is: can we standardize either approach in the relevant standards bodies' specs? Or is there a third way? /be