An array destructing specification choice

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Nov 5 17:40:19 PDT 2011


On Nov 5, 2011, at 2:28 PM, Brendan Eich wrote:

> On Nov 5, 2011, at 10:24 AM, Allen Wirfs-Brock wrote:
> 
>> On Nov 5, 2011, at 9:59 AM, John J Barton wrote:
>> 
>>> ...
>>> 
>>> I don't understand what " the source object is only has two
>>> "array-like" elements" can mean.
>> 
>> 
>> If you used any of the array functions to process _rhs, they would ignore element 2.  For example:
>> 
>> _rhs.forEach(function(v) {print(v)});
>> 
>> would print: 0 1
> 
> Array.prototype.forEach.call(_rhs, function(v){...})
> 
> This has too many moving parts to be a desugaring.

the forEach example isn't part of destructuringing. It is a response to  John saying he didn't know what "array-like" meant.

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. 

> 
> Also a mandatory [[Get]] of 'length' from _rhs before the evaluation of the array pattern is too much.  

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 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. 

Destructuring needs to look at both inherited and own properties (If it doesn't then the behavior of something like {a,b,c} = obj would be dependent upon the inheritance factoring of obj.  That's bad.  obj's inheritance structure should be one of its implementation details and not something that is so easily observable.

The algorithm that would need to be specified to make destructuring rest work with inherited properties but without using length is not simple.  We have a model for what it means to slice an object from a starting index to its "end".  That's the model we should also apply here rather than inventing something new.

Allen








More information about the es-discuss mailing list