Re: What type should .findAll return

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.

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

Received on Friday, 11 November 2011 23:07:43 UTC