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

Re: indexed properties on NodeLists and HTMLCollections

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 23 Jun 2011 15:37:07 +1200
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: David Flanagan <dflanagan@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
Message-ID: <20110623033706.GD7924@wok.mcc.id.au>
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 ≝ http://mcc.id.au/
Received on Thursday, 23 June 2011 03:37:58 UTC

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