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.
>
> 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
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.
> 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.
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.
>
> 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.
Allen
