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
