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

[Nathan Wall]

Hey Allen, thanks for clarifying.

What will happen to other Array methods which currently return Arrays? `filter` is the primary one that comes to mind. Will `uint32array.filter((v) => v != 0)` return a Uint32Array? (I think it should behave the same way `map` does.)

Additionally, what will happen with the return values of `slice`, `splice`, and `reverse`?.. not to mention `concat`, which I know is a much more complex beast.

Nathan




----------------------------------------
> Subject: Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)
> From: allen at wirfs-brock.com
> Date: Wed, 13 Feb 2013 17:49:27 -0700
> CC: claus.reinke at talk21.com; e-tc39 at ecma-international.org; es-discuss at mozilla.org
> To: nathan.wall at live.com
>
>
> 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