

Re: Strategies for standardizing mistakes (was: Notes from Monday's meeting with TC39 folks)

From: Brendan Eich <brendan@mozilla.org>
Date: Tue, 13 Oct 2009 07:44:11 -0700
To: Maciej Stachowiak <mjs@apple.com>
Message-Id: <0CCD3061-4136-435E-B4CE-A298EB490F98@mozilla.org>
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  

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  

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 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?

Received on Tuesday, 13 October 2009 14:45:59 UTC
