This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The named properties object exposes named properties as configurable data properties. There is no special [[DefineOwnProperty]], so we can still define our own on the object. [[DefineOwnProperty]] can successfully set an own property on the object, although named properties will still shadow them when you get them. This allows [[DefineOwnProperty]] to set a non-configurable property, which then can be exposed as configurable if a named property starts existing with the same name later. This breaks an invariant on [[Configurable]]. We could have [[DefineOwnProperty]] force [[Configurable]] = true, just like [[DefineOwnProperty]] for platform objects implementing interfaces that support named properties. Or we could disallow expandos on the named properties object.
I decided just to disallow expando properties altogether on the named properties object. http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.681;r2=1.682;f=h http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=1.123;r2=1.124;f=h
The [[Delete]] defined in the spec now works for ES5 but not ES6: in ES6 [[Delete]] just returns a boolean indicating success or not and the caller throws or not based on strict mode...
Is this behavior for [[DefineOwnProperty]], now basically the same as if the named properties object were considered non-extensible? e.g., it seems weird to get this behavior, yet Object.isExtensible() would still say true? If we changed this to simply mark the option (internally) as preventExtensions() would that do the trick? Of course, it's weird to have own properties magically come and go too, so I'm not sure what's more or less consistent here...?
(In reply to Travis Leithead [MSFT] from comment #3) > Is this behavior for [[DefineOwnProperty]], now basically the same as if the > named properties object were considered non-extensible? No, an object marked non-extensible cannot acquire new own properties (whether via [[DefineOwnProperty]] or via some external means). That's what it means to be non-extensible. I believe Cameron's fix of simply making [[DefineOwnProperty]] reject any updates is fine in terms of ES6 invariants. This could be self-hosted as a proxy that just returns 'false' from its defineOwnProperty trap.