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.
If the rhs was an Array, ..
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'.
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?-).
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'.
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..).
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?-)
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
