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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
