An array destructing specification choice

John J Barton johnjbarton at johnjbarton.com
Sun Nov 6 08:03:03 PST 2011


On Sat, Nov 5, 2011 at 11:16 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> On Nov 5, 2011, at 11:01 AM, John J Barton wrote:
>
> 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.
>
>
> What do you think this returns:
>     Array.prototype.pop.call({0:0, 1:1, length: 2, 2:2})

The answer depends upon the definition of pop(). For an array argument
we can predict based on our experience with pop(). Otherwise we cannot
predict without more information. That's the nature of dynamically
typed language.

Consequently this example does not bear upon the thread in my opinion.
In the example
  let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
the language is inserting some operation to map the RHS to the LHS.
The answer depends upon the operation inserted; it need not be related
to pop().

jjb


More information about the es-discuss mailing list