Any DOM NodeList/"NodeArray" could be converted into a "real" array by passing to Array.from( array like )
http://wiki.ecmascript.org/doku.php?id=strawman:array_extras Avoids creating yet another DOM "NodeThing". /Rick On Nov 11, 2011, at 6:57 PM, Jonas Sicking <[email protected]> wrote: > On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock > <[email protected]> wrote: >> >> On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote: >> >>> On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock >>> <[email protected]> wrote: >>>> >>>> BTW, I think that either the immutable or mutable approach would work. >>>> However, since the collection is not "live" I don't see why you would >>>> really care whether or not a client mutated it. If they want to process >>>> it by deleting elements after they are examined, so what? >>> >>> Exactly, this is why I'm proposing that it should be mutable. >>> >>> This does still leave the problem of making Array.filter(myNodeArray, >>> function(el) { ... }) "work" though. I.e. I think we'd like it to >>> return a NodeArray rather than a plain Array. >> >> This is a problem for ES<=5. Filter and all the other similar >> Array.prototype functions are specified to produce an object created as if >> by calling: new Array(); >> >> I have a scheme that we can probably get in place for ES.next that would >> allow filter and friends to produce NodeArray's for you, but I don't see how >> that helps right now. > > Well, if we can get implementations to implement this new scheme for > the existing filter-like functions at the same time as they implement > .findAll, then we should be golden. > >>> More importantly, we want myNodeArray.filter(function(el){ ... }) to >>> return a NodeArray. This would be doable by putting a special version >>> of filter on NodeArray.prototype which would shadow >>> Array.prototype.filter. >> >> >> It isn't just filter that creates new instances that you would probably want >> to be NodeArrays. Also at least(I might have missed other when I just >> checkeds): concat, slice, splice, map > > Indeed, I was just using filter as an example. > >> Over-riding them explicitly for NodeArray would be an immediate fix, but >> wouldn't solve the problem for future additions to Array.prototype. >> However, if you assume that ES.next is going to provide the needed extension >> mechanism then you should also assume that it will use it for any new >> Array.prototype methods and they should pretty much just work. > > Indeed. If we went down this path we would have to continuously update > the spec to make NodeArray override any filter-like methods that are > added to Array. > >>> This would make myNodeArray.filter "work", but >>> not Array.filter. >> >> An inherent problem with this approach. But if your NodeArrays supplies >> correctly working over-rides there is probably little reason somebody would >> try to use the Array.prototype versions with NodeArrays. > > Note that I was saying Array.filter and not Array.prototype.filter. My > assumption was that if people call Array.prototype with an Array as > the first argument, they would also do so with a NodeArray as first > argument. > >> I don't see a way around this short of modifying the specification of the >> Array.prototype methods. That seems like a job for ES.next rather than a >> DOM spec. > > Definitely, hence the cc :) > >>> I'm happy to start a separate thread on es-discuss about this, but I'm >>> worried that it'll fragment the current thread. >> >> In theory, public-script-coord exists for exactly this sort of discussion >> and the ESdiscuss people who care should be subscripted. Rather than >> starting a new thread, perhaps should should just post to es-discuss a >> pointer to this thread. > > Will do! > > / Jonas >
