Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

[Allen Wirfs-Brock]

On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:

> 
> Allen Wirfs-Brock wrote:
>> ethods.
>> 
>> The choice we agreed to, at the meeting is
>> 
>> 1) Array.prototype.map produces the same kind of array that it was
>> applied to, so:
>> 
>> for the above example m instance of V will be true.
>> intArray.map(v=>v.toSring()) produces an Int32Array.  The strings
>> produced by the map function get converted back to numbers.
>> 
>> 2) If you want to map the elements of an array to different kind of
>> array use<ArrayClass>.from with  a map function as the second
>> parameter:
>> 
>> var strArray = Array.from(intArray, v=>v.toString());
>> 
>> This seemed like a less invasive change then adding additional target
>> kind parameters to Array.prototype.map.  Also it seems like a very
>> clear way for programmers to state their intent.
> 
> You chose one default, but I think it was not the simplest one.
> It is good to see that map is often transforming types, so "the same type" may not be the best default (filter is another story).
> 
> I think the best would be (it is dead simple):
> - to _always_ use Array in map result

In your previous post you said: 

> 1. .map should work for Array subclasses, preserving class


are you changing that position?

Also, there is another subtlety that is on slide 25 of the deck I present.  Existing ES<6 code may create objects that inherit from Array.prototype. When running on an ES6 implementation uses of Array.prototype.map (etc.) in such code can't change their behavior. So, the selection of the result "class" can't be based solely on the [[Prototype]]  inheritance chain. 


> - to leave Array.from (as well as Map.from, V.from etc.) as is,
>   generator comprehension does the mapping for you if you wish one.
> 
> So, the examples would be
> 
>  V.from(x for x in new V); // you say you want the results in V
I don't understand?  This produces the same result as
  new V;
but with an extra V allocation, creation of a generator, etc.

Another issue, is that some array-like "classes" instances must have their size fixed at allocation. This is the case for all the TypedArrays.  For iterators automatically derived from most arrays, we can make the size information available.  But for a generator, there is no way to know how many iterations it will make without actually running it.   For specification purposes, we may specify the "from" method as accumulating the element values into a List, allocatininge most TypedArray uses) that the double copy can be optimized away.  That means that in the usual case the size must be available at the beginning which precludes using a generator expression as the usual case pattern. 

Allen