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

[Allen Wirfs-Brock]

On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:

> 
> 
> Allen Wirfs-Brock wrote:
>> On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
>> 
>>> ...
>>> 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?
> 
> That's probably not me who said it :-)

oops, sorry for the mis-attribution
> 
>> 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.
> 
> I am not TC39 member, so I did not see that slide, but if you say ".map always produces Array", it does not change the behaviour.
> 
> Could you elaborate more, please?

All the presentation decks from the meeting are publicly available at http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013 

the short form:

In ES5, today you can use Array.prototype as the [[Prototype]] of non-Array objects or apply the Array.prototype methods to non-arrays.  The behaviors they get are non-necessarily what you would expect if you would really subclass Array.  We need to preserve the existing behaviors for these existing use cases but would like to provide the more reasonable behavior when class extends Array is used to create a subclass.

Array.prototype.concat is the most problematic of the existing methods in this regard. 
> 
> ...
>> 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
> 
> Hm. Yes, this is problem, then.
> 
>> "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.
> 
> Yes, then the second point is not-starter.
> 
> 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.

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130210/6a4fcfdd/attachment.html>