Why we need to clean up __proto__

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


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.

Allen


More information about the es-discuss mailing list