Re: indexed properties on NodeLists and HTMLCollections

Boris Zbarsky:
> The Gecko behavior here is just really weird.
> …

Thanks for the explanation.  I had noticed something like this (the
order of looking up properties changed things), but hadn’t determined
exactly what the behaviour was.

> I believe not overriding prototype properties is required.
> I'm not sure what behavior I want for own properties, nor whether it
> much matters.

Making own properties not override named properties for non-
[OverrideBuiltins] objects seems slightly simpler conceptually.

> >>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.
> I'm not quite sure how to reconcile that with the [[GetOwnProperty]]
> behavior mentioned above.

Sorry for being unclear: I was pointing out that my intention was to
make only [ReplaceableNamedProperties] objects allow “reconfiguring” the
named property to be a plain, own property that would shadow the named
property, but that there seems to be a bug in my [[DefineOwnProperty]]
that would allow that even for non-[ReplaceableNamedProperties] objects.

> >>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.
> This will likely make definition of expandos somewhat slow, but I
> suppose that's ok; that's a rare case.

Can you explain why that would be?

Also, if there’s a scheme that isn’t slow that you would prefer (and has
the desired compatibility characteristics), I’m happy to consider
changing to that.

Cameron McCormack ≝

Received on Thursday, 23 June 2011 03:37:58 UTC