Re: What type should .findAll return

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 <jonas@sicking.cc> wrote:

> On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock
> <allen@wirfs-brock.com> wrote:
>> 
>> On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote:
>> 
>>> On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
>>> <allen@wirfs-brock.com> 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
>

Received on Saturday, 12 November 2011 01:36:12 UTC