Re: What type should .findAll return

On Fri, Nov 11, 2011 at 10:06 AM, Brendan Eich <brendan@mozilla.org> wrote:
> On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> So, we've debated a lot the exact syntax for .find/.findAll. However I
>> intentionally requested that we split out the discussions about return
>> type for .findAll to a separate thread. So I'm starting that thread
>> here.
>>
>> There are a few goals for the return'ed object that I've envisioned
>> based on discussions so far:
>>
>> 1. It should have at least all of the non-mutating Array methods on
>> it. Possibly the mutating methods too if we allow the returned object
>> to be mutable.
>> 2. It should have a object on the prototype chain where we can insert
>> functions that are specifically useful for lists of nodes. Examples
>> include .find/.findAll/.matchesSelector/.remove/.addEventListener
>> 3. It would be good if it had the Array prototype object on it's
>> prototype chain so that if Array.prototype was extended, it would
>> affect this object too.
>> 4. The object will *not* be live since live results from selector
>> matching is slow.
>>
>> Since the returned object won't be live, I don't see a reason to make
>> it immutable. Hence it seems like we could put Array.prototype on the
>> prototype chain which would immediately make all non-mutating as well
>> as mutating functions available on the object.
>>
>> We should also insert a new prototype object in the prototype chain.
>> Hence we end up with something like:
>>
>> object -> [some type].prototype -> Array.prototype -> Object.prototype.
>>
>> And to ensure that the object acts as much as possible as an array it
>> should also have it's [[Class]] set to that of an array.
>
> This is not something to do lightly -- at least cross-post the first message to es-discuss@mozilla.org and set reply-to followups-to. Cc'ing Allen.
>
> Note that [[Class]] is going away in ES.next.
>
> The internal methods and properties of ECMA-262 are not arbitrary extension points for other specs to use without consultation.

Yup, that's why i cc'ed public-script-coord.

Note that what I'm suggesting in this thread is to create a real
normal Array. "Just" one with an extra object inserted in it's
prototype chain.

So if [[Class]] is going away in ES.next that shouldn't be a problem.
Whatever will happen to Arrays when that happens, should happen to
NodeArrays.

The separate issue of making .filter and friends work can be solved in
multiple ways. At least some of which require no changes to
Array.filter if that is preferable from a language point of view.

Granted, it would be nice if Array.filter(elem.findAll(...),
function(element) { ... }) worked too, and that *would* require
changes to ES.

/ Jonas

Received on Friday, 11 November 2011 18:45:40 UTC