An array destructing specification choice
claus.reinke at talk21.com
Sat Nov 12 14:11:32 PST 2011
>>> This sort of destructuring is not real pattern matching. ..
>> I think this is the important point. Many of us who like "destructuring"
>> are still being mislead by the name, and by our experience with proper
>> pattern matching constructs.
> You just used a different term, "pattern matching", than "destructuring"
> -- so why are you misled?
These terms are not synonyms.
"pattern matching" usually involves matching patterns against something,
where *matching may succeed or fail*. If matching succeeds, we get to
"destructuring", which is *looking at a structure* and *taking it apart*.
The ES.next destructuring proposal does neither matching (patterns
are irrefutable, cf the pattern matching strawman) nor does it look at
the structure (for something to match an Array pattern, it can be an
Array, it can be Array-like, it may just have some numeric fields;
primitive constant patterns are not permitted, and structural
mismatches such as missing object fields just lead to default
assignments, ..). It only does the *taking it apart* bit - so it is
a shorthand for property selectors and slices.
Those of us who are used to pattern matching and its long history
in programming languages are tempted to see more in this feature.
As are those of us who find symmetry between expressions and
patterns appealing from a language design perspective. Because
of this, we are tempted to make suggestions that do not fit the
scope of the current proposal.
As long as the pattern matching strawman is not on the table,
we may have to restrain ourselves, though it is important that
the currently accepted destructuring proposal is spec-ed out
in a form that remains future-compatible with pattern matching.
>> - please rename the current state to "selection shorthand"
> No thanks.
Other suggestions? We've already seen destructuring being
confused with object deconstructors, we are talking about
destructuring as if we had plain data structures (see data
structures strawmen) instead of objects with prototype chain.
And we agree (see pattern matching strawman) that
destructuring is not pattern matching.
The fact that we have talked about prototype chains being
unobservable to destructuring is a clear hint that it is *not*
looking at the structure, but is using abstract object property
selection APIs instead (objects, not records or object literals).
More information about the es-discuss