W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: indexed properties on NodeLists and HTMLCollections

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 15 Jun 2011 16:54:02 -0400
Message-ID: <4DF91BEA.6030409@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
On 6/14/11 3:24 AM, Jonas Sicking wrote:
> On Mon, Jun 13, 2011 at 8:13 PM, Cameron McCormack<cam@mcc.id.au>  wrote:
>> Cameron McCormack:
>>> I would like to hear from implementors whether they
>>>
>>>    1. are happy treating indexed properties as a layer above the normal
>>>       object property resolution (like Chrome/Safari do);
>>>    2. think disallowing user defined non-configurable array index
>>>       properties, or disallowing all user defined array index properties,
>>>       as own properties on NodeLists/HTMLCollections is a good idea.

> I'd really like to hear from bz what he thinks will get the best
> performance in Gecko.

Item #1 above helps performance quite significantly in Gecko's case.

Item #2 doesn't matter either way, I suspect, in terms of performance. 
Since nodelists are dense, it would only matter for access like list[n] 
where n >= list.length, which is comparatively rare.  And even for that 
situation things can still be pretty fast if there are no expandos at 
all.  And in the n >= list.length situation there's some hoop-jumping 
that needs to happen to make things fast (if desired) no matter what, 
because you also have to worry about properties named n on the proto 
chain anyway.

I, too, would welcome feedback from other implementors here.

> Personally I think it makes things the most consistent with JS if
> these properties appear as properties on the object itself as that
> avoids using magic catch-all getters/setters on the proto chain.

I think that's a separate concern.  No one is proposing we use catchall 
getters/setters here.  The only question is how the behavior of the own 
properties is defined.

-Boris
Received on Wednesday, 15 June 2011 20:54:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC