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

[Herby Vojčík]

Allen Wirfs-Brock wrote:
>
> On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:
>> But I still think it is simpler to specify ".map" returning array,
>> always. You know you get an Array, you don't have to worry about magic
>> of Set, Map etc., if you wish to have it in other kind of container,
>> use Container.from(...).
>
>
> But wouldn't you want:
> var my16bitVector = Uint16Array.from([1,2,3,4,5,6]);
> ...
> var y = my16bitVector.map(v=>v+1)
> ....
> someExternalAPI(y);
>
> to create a Uint16Array for y? It seems like the most common use cases
> want to produce the same kind of elements. Mapping to a different or
> broader kind of element is also common, but I think less common. So it's
> the case that should take to more to express.

Well, here's the difference. Nearly every kind of .map use I remember 
(or `collect:` in Smalltalk, maybe I should not mix them but they are 
mixed in my mind) are transformation of the object: map objects to only 
some specific property, wrap collection of primitives to objects that 
are created from them, etc. I honestly can't remember any use of .map 
concept that preserves element types beyond educatory `(1 to: 10) 
collect: [ :x | x*x ]`.

That is, my conviction is, .map is mainly used for bigger 
transformations of its elements (I think your v=>v+1 example much more 
often happens in-place, that is, forEach; map use-case seems rare for me).

> Allen

Herby