Re: What type should .findAll return

On Nov 11, 2011, at 10:44 AM, Jonas Sicking wrote:

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

That's why I'm asking you to cc: es-discuss. I expect Allen will catch up with this thread, but you may get more prompt responses from various people by using es-discuss for the initial message.


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

That's not a "real normal Array" then. Boris mentioned one issue (optimization). Let's call it an extended array. ES.next should support user-extended arrays via the <| operator, so this isn't something "bad", but it's not exactly an array.


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

Allen analyzed how [[Class]] is used in ES1-5, and broke down the cases. Some of these change to a different or more generic way of discriminating on "class". Others still need an internal property. Notable among the latter is the string name disclosed by Object.prototype.toString.call(anArray).

The deeper issue for arrays is the custom [[DefineOwnProperty]] (ES5) or [[Put]] (ES1-3) that maintains length to be one greater than greatest index provided the index is < 2^31 - 1.


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

This sounds right.

/be

Received on Friday, 11 November 2011 20:32:22 UTC