On Nov 5, 2011, at 10:57 AM, Claus Reinke wrote:
>> In the following declaration, what should be the value of z?
>> let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
>
> and there I was, thinking I understood more than half of JS..
>
> Since this was new to me, I referred to the spec. Here <strike>is my
> reading</strike> are my readings:
>
> The rhs is an Object, but not an Array - in spite of duck typing, the spec's
> isArray and Object initializer seem clear on this.
correct
>
> If the rhs was an Array, ..
but it isn't
> object literal instantiation appears to be defined as going from left to
> right, so the '2:2' would increment 'length'.
> I haven't checked the destructuring proposal, but suspect if this was valid,
> the second match for 'z' would just overwrite the first,
> leading to 'z' being '2'.
That's why I'm brought up the issue. The proposal doesn't say. Figuring out
edge cases like this is the job of your friendly specification writer (me...)
>
> However, ..
> since the rhs isn't an Array, but the lhs matches Arrays, I would (now)
> expect this to fail (where is real pattern matching with fall-through when
> you need it?-).
In general, JS, allows an object with integer property names to be used in any
context where an "Array" is expect. This seems like such a context.
>
> Except.. destructuring isn't even structural matching, it is just a concise
> description of object/array selectors. And array selectors are just object
> selectors, no checks for isArray. So the rhs isn't an Array, but the lhs
> isn't one, either, we just get a sequence of selections, and 'z' will be '2'.
except, the LHS selectors are implicit so we can define the rules for
determining them. Also, we allow ... on the LHS and that also implies that
something is going on besides simple sequential integer selector assignment.
>
> This is way too confusing to be nice, or expected. If the spec hard-codes
> the just-selectors-no-matching intuition, this version of the spec will have
> fewer surprises, but yet another syntax will be needed when moving to
> refutable matching in later versions..
> perhaps that's not too bad (except for the fact that I'd like to separate
> objects and arrays more clearly..).
>
I favor consistency. array-like objects should behave consistently in all
contexts. to me that says z should get the value undefined.
> So, do we have to rename 'destructuring' to 'selector
> shorthand', with the braces and brackets only defining
> selection-by-name vs selection-by-index? Or am I way off?-)
I think that is pretty much what the proposed JS destructing really is. I'm
fine with calling it "destructuring"
>
> Claus
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
