An array destructing specification choice

Till Schneidereit tschneidereit at gmail.com
Sun Nov 6 03:53:02 PST 2011


On Sun, Nov 6, 2011 at 03:02, Brendan Eich <brendan at mozilla.com> wrote:
> On Nov 5, 2011, at 5:52 PM, Allen Wirfs-Brock wrote:
>
>> On Nov 5, 2011, at 2:34 PM, Brendan Eich wrote:
>>
>>> On Nov 5, 2011, at 11:27 AM, Allen Wirfs-Brock wrote:
>>>
>>>>> It should, as no length is assumed to mean "length === 0", IIUC, and
>>>>> that seems so unintuitive to me that it sways my opinion towards not
>>>>> imposing array-ness on the RHS.
>>>>
>>>> but that is exactly how it works everywhere else length is used in ES.
>>>
>>> Who says 'length' is used by an array destructuring pattern. That should not be assumed.
>>
>> just to clarify, everywhere else a range of "array" elements is used, the range is limited by the value of the "length" property.  Regardless of where or not the object in question is a "real" array.
>
> Ok, but perhaps we agree, since I've thrown in with Arv on getting 'length' for an array pattern directly containing a ... special form. But not for other array patterns!
>
>
>>>> So you would be fine with the fact that
>>>>
>>>> var r = Array.prototype.slice.call(0:0, 1:1, length: 2, 2:2}, 0);
>>>>
>>>> produces  [0,1]
>>>>
>>>> but
>>>>
>>>> var [...rx] = {0:0, 1:1, length: 2, 2:2};
>>>>
>>>> produces [0,1,2]
>>>
>>> Even if Till would not (and it's clear you would not be fine with this outcome ;-), we have a choice. We can make array destructuring patterns that do not use ... ignore any RHS 'length' property. We could even forbid this kind of "row capture" -- I'm not in favor.
>>
>>
>> I was fine with it to, until ... came along.  If ... uses length (and I think it probably should, as I touched on in another reply) then element access also should)
>
> That "should" doesn't follow. It's a choice and the way you chose violates pay-for-what-you-take. Not something I want in my favored dining establishments. Salad buyer pays for steak? Hmph!

After thinking about this some more, I think I'd be fine with the
above outcome after all. It seems to me as though the array
destructuring pattern really only uses the syntax of arrays, not
necessarily their semantics. Once row capture comes into play, not
even the syntax matches completely, anymore.

The important difference is that, as opposed to the slice example
above, at no point during array destructuring an array object is
created or modified. Given that, isn't the array destructuring pattern
really a convenient way of saying "in this destructuring, all keys are
numeric indices, starting at 0 and increasing linearly by 1"? I.e.,
it's mostly syntax for another form of shorthand, pretty similar to
{x} = {x:1}.

Assuming that, I don't see why length should be used, anymore.

I'm still with Allen on one point: Length should either not be used at
all, or in all array destructuring operations. The alternative would
turn refactoring to ... into a potentially surprising operation for
destructuring, compared to its other uses. Consider
[a, b, c] = {length:0, 0:0, 1:1, 2:2}
//results in a = 0, b = 1, c = 2

Now if that's refactored to
[a, ...r]

if length is used, the result is
a = 0, r = []

if length isn't used, the result is
a = 0, r = [1, 2]

The latter is exactly the behavior of using ... in function signatures
- and, I posit, much less surprising in itself.

I can't say anything about implementation hardships, but from a
usability point of view, I'd say the usage of length should be [no,
no] or [yes, yes], with a strong preference for the former.


till


More information about the es-discuss mailing list