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

[Nathan Wall]

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?

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..?

Nathan