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

Andreas Rossberg rossberg at
Thu Feb 14 08:24:11 PST 2013

On 14 February 2013 02:35, Allen Wirfs-Brock <allen at> wrote:
> 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.)

I'm still not convinced that introducing a separate class only for
masking a handful of length-modifying array methods is worthwhile.
After all, ordinary arrays can be sealed or frozen, too, while still
providing those methods, so typed arrays are not new or different in
that regard.

I'd say that either we properly clean up the Array hierarchy, or we
leave it alone. A half-baked solution that only applies to typed
arrays, and divorces them from the Array hierarchy, seems less
attractive than just doing the naive thing, i.e., TypedArray < Array.


More information about the es-discuss mailing list