- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 21 Jul 2014 11:33:39 -0400
- To: Erik Arvidsson <arv@chromium.org>
- CC: Dirk Schulze <dschulze@adobe.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 7/21/14, 10:28 AM, Erik Arvidsson wrote: > The problem was a combination of instanceof Array and use of > Array.prototype.concat with the node list as one of the arguments. Alright, thanks. So yes, just the concat-spreadable issue. > In some way I'm glad that we failed to ship [ArrayClass] 2 years ago > because in ES5 the array functions are not meant to generate non array > object results. This has also been fixed in ES6, meaning that if we try > this again, `nodeList.map(...)` would now be able to produce a new > NodeList. That would be true if NodeList were a subclass of Array, but not for [ArrayClass] as specced today, which just changes the proto chain. I strongly suspect making NodeList a subclass of Array is not backwards-compatibly enough to be done, though I'd welcome evidence to the contrary... That's ignoring the fact that the generic Array.prototype.map, even if NodeList were an Array subclass, would not be able to produce a NodeList result usefully, because it can't assign things into its indices. > This is important for things like `query(...).map(...)`, which > should return a new Elements collection and not an Array. Sure. New APIs should use Array subclasses. That's not what this thread is about. -Boris
Received on Monday, 21 July 2014 15:34:10 UTC