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