Function identity of non-configurable accessors
Tom Van Cutsem
tomvc.be at gmail.com
Wed Dec 19 05:38:59 PST 2012
2012/12/18 Allen Wirfs-Brock <allen at 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 .
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss