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

Aymeric Vitte vitteaymeric at
Tue Feb 12 03:54:37 PST 2013

Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
> All the presentation decks from the meeting are publicly available at 
> 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) ?

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 :,thisArg, true) or,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...) ?

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.



Email :  avitte at
iAnonym :
node-Tor :
GitHub :
Web :
Webble :
Extract Widget Mobile :
BlimpMe! :

More information about the es-discuss mailing list