B.3.1 The __proto__ pseudo property

David Bruant bruant.d at gmail.com
Tue Apr 23 07:22:55 PDT 2013


Le 23/04/2013 15:53, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 23/04/2013 15:30, Allen Wirfs-Brock a écrit :
>>>> * { [ "__proto__" ]: .... } is not special in any way, and creates 
>>>> a normal property named "__proto__".
>>> I don't believe this is legal. Didn't we agree w to support [ ] 
>>> property keys that evaluate to symbols.
>> I don't know what the agreement is, but that would be wise to forbid 
>> strings in [ ] propert keys given that ES6 introduces Maps which seem 
>> to be a better host for dynamically generated string keys.
>
> What?
>
> Maps are for *abitrary values* as keys -- any type.
>
> Objects have string-equated keys so far. In ES6 we sum symbol | string 
> as the property name type. There is no problem with the o = {[n]: v} 
> syntax for computed property name n (an expression, we argued about 
> wither /Expression/ or /AssignmentExpression/ but I forget the 
> outcome) resulting in either a symbol, or else a value equated to a 
> string as in object literals today.
 From a language perspective, I agree o = {[n]: v} can work with n as a 
string.
 From a developer perspective, I wonder if this isn't confusing as it 
provides another way to do something that's already possible.

     o = {[n]: v}
If n is a string literal, developers might as well get rid of the 
brackets. In all other cases, the following work already:
     o = {};
     o[n] = v;

If someone feels like doing:
     o = {
         [a]: v1,
         [b]: v2,
         [c]: v3,
         [d]: v4,
     }

Maybe what they want is a Map (dynamically computed strings) or an array 
(fixed length).

I don't see a use case where dynamic key strings in object literals is a 
good idea.

David


More information about the es-discuss mailing list