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

Herby Vojčík herby at mailbox.sk
Tue Feb 12 02:37:07 PST 2013



Rick Waldron wrote:
>
>
> On Monday, February 11, 2013, 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
>     <http://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..?
>
>
> Since you're using Array.prototype.map there, your code will indeed give
> you an array of string IDs, as it always did.

No it won't. In the current proposal (which I'd like to change, I think 
Array is better default container for map), if NodeList would subclass 
Array, applying (generic) Array.prototype.map on instance of NodeList 
would create a new NodeList and would try to put ids on there.

Herby

> Rick
>
>
>     Nathan


More information about the es-discuss mailing list