Re: indexed properties on NodeLists and HTMLCollections

On 6/21/11 1:36 PM, David Flanagan wrote:
> On 6/16/11 7:42 PM, Cameron McCormack wrote:
>> Cameron McCormack:
>>> My plan was (and I’ve written a patch to the spec to do this but 
>>> haven’t
>>> committed it yet) to redefine [[GetOwnProperty]] (as opposed to 
>>> [[Get]])
>>> to make it appear like real own properties exist on the object.
>> I’ve made this change now.  I’ve done it for named properties too, but I
>> still need to do a bit of testing around that.
>>
> My new reading of this new definitions of [[GetOwnProperty]] is that 
> for interfaces like HTMLCollection that do not OverrideBuiltins, both 
> built-in properties on the prototype and expando properties on the 
> collection itself hide named properties. I'd like to double-check that 
> this is intentional since Firefox and Chrome seem to have named 
> properties hide expandos.
>
>     David
>

My reading of [[DefineOwnProperty]] for named properties was that we 
ought to be able to define an expando property x even when a named 
property x also exists, and that the new expando will hide the named 
property.

However, while writing my proxy-based implementation of HTMLCollection, 
I discovered that the default proxy handler set() trap does not call the 
defineProperty() trap when you try to set an existing read-only 
property.  In that case, it simply ignores the attempt to set the 
property.  I suspect that is what the ES-262 says to do even without 
proxies, so my new interpretation of how named properties and expandos 
should interact is the following:

1) A pre-existing named property will prevent the definition of an 
expando property with the same name, so there is no shadowing issue.

2) A pre-existing expando will shadow a named property that comes into 
existance after the expando. [This is different than the current 
behavior of FF and Chrome, at least.]

Is this the intent of the spec?

     David

Received on Tuesday, 21 June 2011 22:43:46 UTC