# An array destructing specification choice

John J Barton johnjbarton at johnjbarton.com
Sat Nov 5 11:01:58 PDT 2011

```On Sat, Nov 5, 2011 at 10:24 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
>
>>>
>>
>> (Oh great more features that turn programming into little brain teasers :-( )
>>
>> Devs need an algorithm:
>>
>> let _lhs = [];
>> let _rhs =  {0:0, 1:1, length: 2, 2:2};
>> _lhs[0] = _rhs[0];
>> _lhs[1] = _rhs[1];
>> _lhs[2] = _rhs[2];
>> let z = _lhs[0];
>> let y = _lhs[1];
>> let z = _lhs[2];
>>
>> So z would be 2.
>>
>> I guess the algorithm can be shorter:
>> let _rhs =  {0:0, 1:1, length: 2, 2:2};
>> let z = _rhs[0];
>> let y = _rhs[1];
>> let z = _rhs[2];
>>
>> I don't understand what " the source object is only has two
>> "array-like" elements" can mean.
>
>
> If you used any of the array functions to process _rhs, they would ignore element 2.  For example:
>
>  _rhs.forEach(function(v) {print(v)});
>
> would print: 0 1

I can see why my version is wrong: I am interpreting square brackets
on the RHS like JS devs would.
let z = _rhs[0]; // LHS was array, so get zeroth elt,but RHS is
object so property access.

But the feature does not do this. Rather, since LHS is array, it
coerces the RHS to an array:
let z = coerceToArray(_rhs)[0];
and we don't know what that operation means.

This example illustrates (again) why implicit type conversions sucks
(except to strings ;-).

Can't this just be a error?

jjb

>
>
> Allen
>
>
>
>
```