Re: indexed properties on NodeLists and HTMLCollections

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

I believe I wrote that intentionally.

Try this test on HTMLCollection:
http://people.mozilla.org/~cmccormack/tests/named-property-override.html

It looks like Firefox, Chrome and Safari treat the interface as
[OverrideBuiltins] while Opera and IE treat it as non-
[OverrideBuiltins].

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

Only if [ReplaceableNamedProperties] is used on the interface.
Otherwise (assuming there is no name setter), it will fall through to
invoking the default [[DefineOwnProperty]] method and … oh, I see, this
will succeed in reconfiguring the property.

(Actually, it is probably a violation of an assertion somewhere: when
the default [[DefineOwnProperty]] calls [[GetOwnProperty]] at the top,
it assumes that if it gets a property descriptor back that there is an
own property on the object.  This isn’t the case with our HTMLCollection
object though!)

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

Yes, it’ll call [[CanPut]] first to determine whether to attempt to
reconfigure the property, right?

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

Yes, that is the intent.  I think then that Web IDL’s
[[DefineOwnProperty]] needs to change to ensure (1).  (2) should already
work.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 22 June 2011 04:18:08 UTC