2012/12/18 Allen Wirfs-Brock <al...@wirfs-brock.com> > > On Dec 18, 2012, at 9:08 AM, Brendan Eich wrote: > > Mark S. Miller wrote: > > That could work, but because of its complexity, I'm leaning back towards > the "configurable data property that refuses to be configured" approach. Is > there a problem with that? It self-hosts fine. > > > Certainly this is the simplest solution. It has a slight smell, but no > worse than the others'! > > > I'm really bothered by this concept. It seems to be saying: > > For my important use cases, I must be able to depend upon the meaning of > [[Configurable]]: false. So implementation must take all measures > necessary to ensure that meaning. However, I don't care about other use > cases that might depend upon the meaning of [[Configurable]]: true. I > think its fine that an implementation lies and says that an object is > configurable when it really isn't. > > > This really seems like a double standard. Integrity issue are important, > and in some cases may need to be given special consideration, but we need > to consider the full spectrum of use cases. > > Regarding simplicity. I don't really see it. > > For example, we presumably still want global object bindings introduced > via var to not be deletable via delete (unless they were introduced using > eval). How do we express the link between the semantic of var and delete > if we can't use [[DefineOwnProperty]], [[GetOwnProperty]] and the > [[Configurable]] attribute . Instead we have to define some new > mechanism/state to establish this relationship [1]. >
I too find the solution of non-configurable data properties masquerading as configurable data properties bothersome. We have a mechanism in place for describing the behavior of ES5 properties, yet here is a case where we can't be honest about a property's real behavior. That smells. The issue seems to be that there are two "access rights" to this data property: external clients are only allowed to read, but not write to the property (that is why it should really be reflected to clients as non-configurable). Some privileged code, however, is allowed to write to the property (that is why we cannot really make it non-configurable). Implementing these access rights is easy to achieve using an accessor property, so it seems logical to turn this property into an accessor. Why can't we make it a non-configurable accessor property? I don't understand the leak described by David in the OP. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
