Function identity of non-configurable accessors

Allen Wirfs-Brock allen at
Tue Dec 18 09:38:55 PST 2012

On Dec 15, 2012, at 2:51 PM, David Bruant wrote:

> Le 15/12/2012 16:14, David Bruant a écrit :
>> Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
>>> If I create a non-configurable property with a getter that I define (such
>>> as `() => 3`), I know that accessing the property will always produce
>>> a known value.    Relaxing this restriction means that proxies could
>>> produce whatever they wanted in this situation.
>> Indeed. Note that it's true currently true with ES5 host objects.
> I'd like to add that you can defend yourself by checking if the reflected function is the one you put in there.
> As far as expecting some behavior on [[Get]] or [[Set]], nothing prevents a proxy from either not calling the getter/setter you passed or do call them but do/return whatever inconsistent with the accessor. Or why not call the setter on [[Get]] and the getter on [[Set]].
> That might be one reason why there was no invariant regarding accessors in ES5.

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.

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.

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.


> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list