- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 23 Jun 2011 15:25:53 +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: > > > 1) A pre-existing named property will prevent the definition of > > > an expando property with the same name, so there is no shadowing > > > issue. … > I'm thinking about point 1 again after a good night's sleep... My > phrase "prevent the definition of" conflates two things: ordinary > property assignment which rejects attempts to set own properties > without ever calling [[DefineOwnProperty]] and explicit calls to > Object.defineProperty(). You are right that the prevention of property assignment could be done either in [[Put]] or in [[DefineOwnProperty]]. [[Put]] does call [[DefineOwnProperty]] to do the actual property creation/modification, though. > Named properties look like configurable read-only own properties. > If these were on an ordinary JavaScript object, then attempting to > set them with ordinary assignment would fail, but setting them with > an explicit call to Object.defineProperty() would succeed. Yes. Though I only made them configurable because with the proxy proposal you wouldn’t be able to expose a non-configurable property. I think there was talk of allowing certain properties to be exposed as non-configurable, but that still wouldn’t work here since these properties still need to be able to change. Allen mentioned that it is fine to refuse to reconfigure a property even if it is configurable, and I just thought I would go the simpler route and disallow it. > That, I think, is the behavior that the spec already has in its > current state, and maybe that is just what we want: you can't override > a named property accidentally, but you can if you really want to. Actually I intended to disallow it, even with Object.defineOwnProperty, when writing the text. I don’t think it particularly matters whether we allow this or not, though. Are there any disadvantages either way? > On the other hand, I suppose that is what > [[ReplaceableNamedProperties]] is for. Named properties on > interfaces with ReplaceableNamedProperties are supposed to be > replaceable through regular assignment and not just through > Object.defineProperty(), right? Right. > I don't think that works currently. Maybe in [[GetOwnProperty]] > step 2.7, make the property writeable if there is a setter or if > [[ReplaceableNamedProperties]]? Oh yes, you are right. [[Put]] will call [[CanPut]], which will return false for the non-writable property descriptor returned from Web IDL’s [[GetOwnProperty]]. (I’ll make your suggested change now.) -- Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 23 June 2011 03:26:34 UTC