- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 22 Jun 2011 16:17:24 +1200
- To: David Flanagan <dflanagan@mozilla.com>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, Jonas Sicking <jonas@sicking.cc>, Allen Wirfs-Brock <allen@wirfs-brock.com>, public-script-coord@w3.org
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