Function identity of non-configurable accessors

Tom Van Cutsem at
Wed Dec 19 05:38:59 PST 2012

2012/12/18 Allen Wirfs-Brock <allen at>

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list