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