An array destructing specification choice

Brendan Eich brendan at mozilla.com
Sun Nov 6 21:13:55 PST 2011


On Nov 6, 2011, at 11:18 AM, Allen Wirfs-Brock wrote:

> On Nov 6, 2011, at 3:53 AM, Till Schneidereit wrote:
>>> ...
>> 
>> After thinking about this some more, I think I'd be fine with the
>> above outcome after all. It seems to me as though the array
>> destructuring pattern really only uses the syntax of arrays, not
>> necessarily their semantics. Once row capture comes into play, not
>> even the syntax matches completely, anymore.
> 
> I'm skeptical of ES every supporting row capture.  It is essentially an shallow copy (with exclusions) operation and it brings into to play all the copy semantics issues that up to this point we have been unwilling to try to take on.

We have JS code such as Prototype's Object.extend that do for-in loops copying (own and inherited) enumerable properties from src to dest. It's not a problem.

Why wouldn't row capture work similarly? Perhaps only own enumerable properties. Or all own properties, but the point is there's no deep clone complexity.


>> The important difference is that, as opposed to the slice example
>> above, at no point during array destructuring an array object is
>> created or modified.
> 
> Well, a (real) array object is created is a rest pattern is used.

Why?


>> Given that, isn't the array destructuring pattern
>> really a convenient way of saying "in this destructuring, all keys are
>> numeric indices, starting at 0 and increasing linearly by 1"? I.e.,
>> it's mostly syntax for another form of shorthand, pretty similar to
>> {x} = {x:1}.
> 
> or does the use of the [ ] pattern also imply some deeper user intent about applying array-like semantics. 

Not in our experience, or Opera's, or Rhino's.

Maybe this is an edge case and I should quit beefing. However I do not like the aesthetics or the economics of a spec that gets 'length' for all array patterns, even if not needed.


> For [no, no] to implement ... we have to assume that the iteration limit is the max possible array index (currently Uint32 max - 1,

No. We only need look at the properties that are actually present. I think you are dismissing row capture in object patterns and therefore focusing too narrowly on the "array" word in array patterns. If we want row capture in both, it will entail enumeration of actual properties, not wild integer counting till 2^32 or 2^53.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111106/688a1161/attachment.html>


More information about the es-discuss mailing list