An array destructing specification choice

Brendan Eich brendan at mozilla.com
Sat Nov 5 18:58:22 PDT 2011


On Nov 5, 2011, at 5:40 PM, Allen Wirfs-Brock wrote:

> In general, destructuring already has too many moving parts to simply be a simple desugaring.  array/object distinctions, rests on the LHS, default value specifiers, etc. I'm specifying it like any other feature in the language. 

Take away "rests" and what remains is desugaring or local transformation, no new semantics. Let's look:

[x, y] = a  =>  t = a, x = t[0], y = t[1]

{p:x, q:y} = o  =>  t = o, x = t.p, y = t.q

[z = w] = a  =>  t = a, (z = (0 in t) ? t[0] : w)

{r: z = w] = o  =>  t = o, (z = ('r' in t) ? t.r : w)

These compose straightforwardly. The {x} shorthand for {x: x} is even simpler.


> That's what lead me to post the original questions.  I realized that I needed to carefully manage access to the "length" property.  I now have it specified so that exactly one "length" access is need for each "array" destructuring, regardless of the number of elements that are assigned or whether a rest is involved.  That seems potentially reasonable.

I don't think it is good to get 'length' if there's no rest. It's pure overhead for no reason. If 'length' has an effect-ful getter on some arraylike, there's no win in saying all array patterns invoke it. Rather, such a nasty array-like would be better avoided, but if it is used, the pay-only-for-what-you-take argument applies. IOW, I agree with Arv.


>> I don't see why 'length' needs to come into play unless there's a ... in the pattern, or even then. The alternative is to enumerate keys of _rhs and consider all for which key == ToString(ToUint32(key)).
> 
> 
> Do you want a consistent set of rules for dealing with "array-like" objects or do you think it is ok to make up rules for each new function or operation we invent.  Right now, we have a very consistent processing pattern that is followed by all the array related functions that process multiple elements. That pattern is driven off of an initial length determination at the beginning of the algorithm. 

Only when length is needed. It's not if there's no use for it. In the current controversy, it shouldn't be got if there's no rest in the enclosing array pattern.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111105/2054453d/attachment.html>


More information about the es-discuss mailing list