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

[Allen Wirfs-Brock]

On Feb 12, 2013, at 4:54 AM, Aymeric Vitte wrote:

> 
> Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
>> 
>> 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.
> 
> After reading this thread and the slides, what is the plan for Typed Arrays (dedicated array like methods or Array subclassed like) ?

As we discussed at the meeting,  to rationally place Typed Arrays into the same class hierarchy as Array would require refactoring Array.prototype into multiple abstract superclasses.  This seems like too large of a change.  Instead the plan that we agreed to  is to introduce TypedArray as an abstract superclass of all of the specific Typed Array constructors.  TypedArray.prototype will be specified to have all of the Array.prototype methods that don't dynamic change the length of an array.  (TypedArray.prototype will also define set and subarray from the Khronos Typed Array spec.)

How I hope to specify TypedArray.prototype is to say that any of its properties that are the same as the corresponding Array.prototype property may, at the discretion of the implementation,  be implemented using the same function objects as Array.prototype or by using a different function that conforms to the same specification.  This would give an implementation an option of using either the same Array.prototype methods or of providing versions of the methods that are optimized for use with Typed Arrays. 

It's possible that this may not fly. Such a choice of implementation approach allows more freedom then we normally give implementations and the choice would be detectible by user code doing something like: Array.prototype.map === TypedArray.prototype.map

 If we find we can't allow that flexibility my next choice is to to say that both Array.prototype and TypedArray.prototype share in common those function objects and leave it to implementations to hide any Type Array specific optimizations inside of the functions.  The reasons this is my preference, over simply saying they are all different function objects that share a common specification, is that I'm generally trying to minimize the number of new built-in functions  that need to be created every-time a Realm (eg, iframe)  is created. 


> 
> I see the constraints for subclassing, but the solution a.from(b,map) seems a little bit strange (even if I agree that it should return the same instance as a) , and what about concat, slice, etc as you mention? Couldn't we add something like a parameter to the methods : example.map(f,thisArg, true) or example.map(f,true) returns example's instance instead of Array (same processing as .of, .from), so you can explicitely say that you want to return the same instance and don't have backward compatilities issues (hopefully...) ?

note it is A.from(b,mapfn), eg; Array.from(b, mapfn) or Uint32Array.from(b,mapfn).  A boolean valued parameter isn't sufficient because you need the flexibility to identify the specific kind of array you want to map into.

Either of the above read perfectly fine to me:  I want to create a new Array (or Uint32Array) from the elements of b transformed by mapfn.  All the essential pieces of information are there and the conceptual model seems just fine.


> 
> I have used a lot Typed Arrays for [1] [2] [3] and all along wondering why Array like optimized methods were not available, especially concat, and why it was speced entirely in TC39 while a spec already exists (which specifies slice/subarray but surprisingly not concat), but it will be extremely usefull to have the Array like methods in the ES specs for Typed Arrays.

The intent of TC39 adopting Typed Array is to allow us to fully integrate it into the language, rather than it being a "add on" that doesn't follow the normal ES conventions. Make the (applicable) Array.prototype methods available is part of that integration. 

Allen


> 
> Regards,
> 
> [1] https://www.github.com/Ayms/node-Tor
> [2] https://www.github.com/Ayms/iAnonym
> [3] https://www.github.com/Ayms/node-typedarray
> 
> -- 
> jCore
> Email :  avitte at jcore.fr
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>