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

[Allen Wirfs-Brock]

On Feb 11, 2013, at 7:13 PM, Nathan Wall wrote:

> Thank you for this explanation.  This is very interesting!  If you don't mind, I have some questions/concerns I'd like to clear up.  (In particular I want to make sure I understand; I don't intend to argue for one side or the other ATM, but this change may require me to refactor some old code to be future-ready).
> 
> Allen Wirfs-Brock wrote:
>> The choice we agreed to, at the meeting is
>> 
>> 1) Array.prototype.map produces the same kind of array that it was applied to, so:
>> 
>> for the above example
>> m instance of V will be true. 
>> intArray.map(v=>v.toSring()) produces an Int32Array. The strings produced by the map function get converted back to numbers.
> 
> Sounds cool! Does it work?
> 
> I rely on the genericness of Array methods quite a lot. For example, it's fairly common for me to write something like the following:
> 
>     var map = Function.prototype.call.bind(Array.prototype.map),
>         select = document.querySelectorAll.bind(document);
> 
>     var ids = map(select('div'), function(el) { return el.id; });
> 
> Currently this would get me an array of string ids for every div on a page. In a future ES6 with a future DOM where NodeList extends Array, will `ids` no longer hold an array of strings but try to remain a NodeList?

Anything that works with ES5 semantics should continue to work, assuming nothing else changes.

If NodeList was turned into an actual subclass of Array, then the default behavior of Array.prototype.map when applied to a NodeList will be to create a new NodeList, assuming that NodeList supports all the mechanism that map uses to create its result object.  Of course, the design of this new NodeList has the option of over-riding the inherited definition of map and/or opt-ing out of the create something other than Array instance behavior.

Regardless, because of backwards compatibility concerns, I'm skeptical that NodeList could ever be made into an Array subclass.  It seems more likely that a new kind of DOM Node collection  that was an Array subclass might be introduced 

> 
> There's a good chance this will break some of my code. I'm capable of changing my code and writing this to be more future-friendly from now on (I'm not one who prefers backwards compatibility over a better language). But I would have always assumed I was doing things correctly before, and I'm curious if the rest of the internet will be okay..?

We can't break existing code.  Where things get messy is when old code is combined with new code that uses new features. For example, you map function will produce a SubArray  instance if it is called with a SubArray instance assuming that SubArray is a real ES6 subclass of Array as its first argument.

Allen