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: al...@wirfs-brock.com
> Date: Wed, 13 Feb 2013 17:49:27 -0700
> CC: claus.rei...@talk21.com; e-t...@ecma-international.org;
> es-discuss@mozilla.org
> To: nathan.w...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
