Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
herby at mailbox.sk
Mon Feb 11 03:04:57 PST 2013
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)
> 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).
More information about the es-discuss