__proto__ in Annex B

[Brendan Eich]

On Sep 29, 2011, at 7:34 PM, David Bruant wrote:

> Le 29/09/2011 20:10, Brendan Eich a écrit :
>> On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
>> 
>>> On 28/09/11 00:06, Waldemar Horwat wrote:
>>>> Should we standardize __proto__ in Annex B?
>>>> MarkM + a few others:  Yes
>>>> Waldemar, Doug:  No
>>> Unless we have a definite plan that no ES.Next impl will support __proto__, then by all means don't standardize it.
>> It is a standard (de-facto)
> What is a de facto standard exactly? The fact that '__proto__' allows to
> get and set the prototype? This basic definition stands, but I have
> heard of bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=690027
> 
> Firefox 7 recently added a '__proto__' property to Object.prototype
> (https://bugzilla.mozilla.org/show_bug.cgi?id=690031). Would it be part
> of the non-mandatory spec?

We did not recently add anything to Object.prototype. We had a very old (13 years?) __proto__ property that appeared to be "own" by the obvious tests, but which was on Object.prototype (you could tell with less obvious tests such as the one in the first bug you filed, 690027). Here's a session in a 2008-era (Firefox 3) js shell I keep around:

js> Object.prototype.hasOwnProperty('__proto__')          
true
js> Object.prototype.hasOwnProperty.call({}, '__proto__')
true

In the latest SpiderMonkey,

js> Object.prototype.hasOwnProperty('__proto__')
true
js> Object.prototype.hasOwnProperty.call({}, '__proto__')
false

We got rid of the old non-standard hack by which __proto__ appeared to be "own". That seems worse to me, but (see below) I'm not losing sleep over it right now.

BTW, we do properly parse JSON that defines a key named "__proto__", and IIRC V8 does not. I suspect (haven't checked) that V8 and other engines that say __proto__ is not "in" and in particular not "own" for any object, but which implement it, do so as Rhino does, with special casing in [[Get]] and [[Set]] equivalents.

I'm not sure what we would spec if we did make an optional Annex B spec, at this point. But we could argue about it if that seems worthwhile (it doesn't right now to me).


> Making __proto__ part of the spec sounds like an incitation to authors
> to use it.

No, the Annex B stuff does not "incite" anyone.

The problem is people already use __proto__. Turning a blind eye in the spec doesn't stop them. Apparently IE is feeling heat to implement. See Thomas Fuch's Zepto library, popular on mobile. Nothing in any spec could incite what has already happened.


> I agree that implementors should agree for interoperability
> purposes, but I'm not sure the official ECMAScript standard is the right
> place to do so since it is intended for authors as well.

Annex B is already full of such stuff.

We were only ever talking about Annex B. That was made clear in this thread. That must matter, given the precedent already there, ignoring __proto__.

You do raise the point that if the intersection semantics are too thin, or we can't agree on standardizing only [[Get]] and [[Set]] hardcoding, then some implementations will have to adjust. That may happen anyway.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/4b012eed/attachment-0001.html>