Why we need to clean up __proto__

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Dec 29 15:27:39 PST 2011


On Dec 29, 2011, at 2:00 PM, David Bruant wrote:

> Le 29/12/2011 18:13, Allen Wirfs-Brock a écrit :
>> On Dec 29, 2011, at 4:58 AM, David Bruant wrote:
>> 
>>> Le 29/12/2011 03:04, Mark S. Miller a écrit :
>>>> Darn. I completely missed that. No easy fix comes to mind. Suggestions?
>>> I think '__proto__' in object literals should work like any property. The ES.next proto operator [1] creates a standard alternative to using __proto__ in object literal.
>>> ...
>>> __proto__ would then act like a regular property (shadowing the one on the Object.prototype, very much like if it had been added with Object.defineProperty). The ability to later change the prototype is not lost as Lasse suggested.
>>> 
>>> I don't know to what extent my suggestion would break exisiting scripts. Neither do I know whether breaking existing __proto__-using scripts is a good or a bad thing.
>>> If in some browsers it breaks something, browsers, when changing __proto__ semantics could issue a warning in their console ("you're using __proto__ in object literals and we have changed its semantics...").
>> The only reason to even consider a normative definition for __proto__ is because it already exists on the web. If that definition doesn't support its common usage patterns than there isn't much point in doing it.
>> 
>> We really should be starting from an analysis of the actual intersection semantics of __proto__ among the major web browsers.  Mark's test in his original post is just a start at that analysis. 
>> 
>> Personally,  given that IE as yet to support it, I think there is a good argument that the intersection semantics is empty and at the very least __proto__ in object literals  it should be banned in ES.next Harmony mode.
> I'm not sure I understand. I suggest to ban '__proto__' for object
> literals, you seem to disagree based on the fact that __proto__ should
> be standardized based on the intersection of current implementation
> semantics, then you suggest to ban __proto__ in object literals. Am I
> misinterpreting what you answered?

The plan of record of TC39 is to specify __proto__ in Annex B and to change the status of Annex B to Normative/Optional.  This means that it doesn't have to be implemented, but if it is it must follow the specification.

The argument, in favor for specifying it is that it is a de facto feature of browsers particularly in the mobile space.

I'd prefer not having __proto__ at all, but if we must have it then I would prefer to keep it out of "Harmony mode" code. 

> 
> Also, you mention "in ES.next Harmony mode". What is the plan regarding
> __proto__? To standardize it also for ES5? What is the scope of the next
> version of the standard? Does it standardize ES5, ES5+strict mode and
> ES6 (or whatever number)? Will the standardization of __proto__ also be
> part of an ES5.2?

This is about specifying it in "ES6". This has no normative impact on ES5.x but but future implementors of such might well follow the ES6 specification when implementing this non-standard (for ES5.x) feature.

I don't believe that we have previously discussed the possibility of variations of __proto__ among the various "ES6" modes.  That is what I am now suggesting, precisely to avoid issues like the one you mention below


> 
> If the idea is only to standardize __proto__ and its interaction with
> ES6 and __proto__ was not considered as a regular property, then, what
> would be the semantics of:
> -----
> var o = myProto1 < {
>  __proto__: myProto2,
>  a: 1,
> };
> -----
> 
If we disallow any special meaning of __proto__  in object literals in ES6 Extended code ("Harmony mode") then the above would simply define __proto__ as a regular data property of the new object.  If we don't disallow the special meaning then we will need to define what exactly this means. I vote would be Syntax Error.

Also, note that any use of __proto__  in a object literal that is expected to set [[Prototype]] requires special specification treatment (for any mode).

Allen







> David
> 



More information about the es-discuss mailing list