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

Brendan Eich brendan at mozilla.org
Tue Oct 13 07:44:11 PDT 2009


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


More information about the es-discuss mailing list