Function identity of non-configurable accessors

Mark S. Miller erights at
Tue Dec 18 10:34:30 PST 2012

On Tue, Dec 18, 2012 at 9:38 AM, Allen Wirfs-Brock
<allen at> wrote:
> The whole whole idea of such invariants was a late addition to ES5, and not without some controversy. I don't think anyone believed that ES5 had a complete set of invariants or even what that might be.

As part of the proxy work, Tom and I have started a more complete list
of invariants. Yes, it would be good to make more progress on this.

> Regarding the identify of stored/retrieved get/set functions, for "ordinary objects" that is fairly explicit in the ES5 spec. [[DefineOwnProperty]] sets a properties internal attributes to the provided values and [[GetOwnProperty]] retrieves the values of those attributes.  The only specified way to modify the identify of such a stored get/set attribute would be by an intervening [[DefineOwnProperty]] call.  Hence, we have identify preservation across setting/retrieving of get/set accessor functions.  I've thought about making this even more explicit, but the ES5 language seems clear enough.

Agreed so far.

> For "exotic objects", as is usual for most such hypothetical invariants, anything goes in ES5.  So, a host object could change the identity of a get/set accessor function. That doesn't bother me,  "exotic objects" are an escape mechanism for unanticipated new semantics.  But, the provider of such an object really needs to fully document its behavior.  Otherwise, its not going to be very useful.  But if the documentation says that the identify of get/set functions are not preserved, then that seems like sufficient warning.

This seems nonsensical to me. At
<> is my
summary of the point of some of these invariants -- that no state
transitions beyond those shown in this diagram are possible. When
David pointed out the getter/setter identity stability invariant was
missing, this surprised me. It is clearly an oversight. It never
occurred to me when drawing this diagram that the lack of
getter/setter change applies only to ordinary objects.

JavaScript is a very dynamically typed language. Static reasoning
proceeds safely often without knowledge of the object types of the
values involved, nor (as usual) of potential aliasing. These
invariants enable useful static reasoning precisely because they are
universal (and so not type dependent) and monotonic (and so aliasing
independent). Further, as I've mentioned several times, direct proxies
can leverage the presence of a single invariant-violating exotic
object to create any number of other invariant violating objects.


More information about the es-discuss mailing list