July 25, 2012 - TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Wed Aug 1 05:59:41 PDT 2012


Le 01/08/2012 00:05, Brendan Eich a écrit :
> David Bruant wrote:
>> From a practical point of view, if 2 implementations differ on one 
>> aspect of the language, it means that there is no content relying on 
>> either of the 2 implementations for that aspect of the language, 
>> whether they follow the spec or even both diverge differently from it.
>
> It's not that simple on the web. For instance, longstanding IE vs. 
> Netscape/Mozilla forking, e.g.
>
>   if (document.all) { ... } else { ... }
>
> can mean some divergence among the "else" browsers is ok because not 
> relied on there, but not ok in the "then" case.
What an intricated case.
By the way, I recall something I learned from @mathias. In Chrome:

     console.log(document.all); // shows an object in the console
console.log(typeof document.all) // undefined
     'all' in document // true
     console.log(!!document.all) // false

Such a thing cannot be represented in pure ECMAScript, not even with 
proxies. I don't think there is anything that can be done in ECMAScript 
to fix this, but it's worth sharing this information.

> You're probably right, but we are not making data and accessors 
> asymmetric in the sense that a non-writable data property and a 
> get-only accessor on a prototype object both throw (strict) or 
> silently fail to update the LHF (non-strict) on assignment that would 
> otherwise create a shadowing property in a delegating object.
>
> This was debated at last week's TC39 meeting. Between the desire to 
> preserve this symmetry (not paramount, there are many dimensions and 
> symmetries to consider) and the V8 bug being fixed (and the JSC bug on 
> which the V8 bug was based already being fixed in iOS6), I believe we 
> kept consensus to follow the spec.
That's fine. I was only noting that the door was open. There is no 
reason to be forced to take it. Interoperability is however a good 
reason to make a choice whatever it is.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120801/3f18cc7e/attachment-0001.html>


More information about the es-discuss mailing list