An array destructing specification choice

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Nov 5 10:10:09 PDT 2011


On Nov 5, 2011, at 9:59 AM, Lasse Reichstein wrote:

> On Sat, Nov 5, 2011 at 5:28 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> In the following declaration, what should be the value of z?
>> 
>> let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
> 
> (I assume the pattern should be [x,y,z], not [z,y,z], or am I missing a point?)

oops...

> 
>> should it be be 2 or undefined
> 
> If it does anything at all (and not, say, throw a TypeError because
> the RHS isn't an Array, which it won't), I'd go for 2.
> 
> There is no reason to involve RHS.length at all. The LHS isn't an
> array, why should it require array-like-ness of the RHS. The LHS
> together with the assignment operator is a construct that binds the
> properties "0", "1", and "2" of the object on the RHS to the variables
> "x", "y", and "z". It should be equivalent to the pattern {0:x, 1:y,
> 2:z}.

then what are the rules if ... is  used on the LHS.

> 
> What if the RHS doesn't have a length property at all? Or it has one
> with a value that isn't convertible to a number? No need for that
> complexity.

This case is consistently handled throughtout the ES spec:
    ToInteger( obj.[[Get]]("length"))
evaluates to 0 if length is missing or has a bogus value.

> 
>> undefined might be reasonable because it is an array pattern, and the source object is only has two "array-like" elements
>> 2 might be reasonable because the source object actually has a property named "2"
>> 
>> Which alternative will be least surprising to JS programmers?
> 
> Mine, obviously. At least the least surprising to me.
> I've learned not to generalize from that.
> 
> /L
> 



More information about the es-discuss mailing list