- From: Brendan Eich <brendan@mozilla.org>
- Date: Tue, 13 Oct 2009 07:44:11 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Mark S. Miller" <erights@google.com>, Simon Pieters <simonp@opera.com>, Anne van Kesteren <annevk@opera.com>, Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org, es-discuss Steen <es-discuss@mozilla.org>
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
Received on Tuesday, 13 October 2009 14:45:59 UTC