Function identity of non-configurable accessors

David Bruant bruant.d at
Sat Dec 15 12:35:29 PST 2012

Le 15/12/2012 19:11, Brendan Eich a écrit :
> David Bruant wrote:
>>> 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.
>> The frozen getter/setter could be a working solution as well. 
> Frozen accessors would be best if we can get away with the 
> incompatibility.
I've given more thought. Frozen accessors can't be a solution. Only 
deeply frozen would be. If the accessor isn't deeply frozen, then, it 
means that any non-frozen object that can be reached through the 
accessor can be used as a communication channel between 2 browsing 
contexts that were in the same iframe.
Among other things, "deeply frozen" means to freeze the accessor's 
[[Prototype]] which is Function.prototype which is probably not workable.

Or there are probably other things like comparing iframes 
contentWindow.Function.prototype objects over time (when changing src) 
that wouldn't be compatible.

Back to the idea of reflecting different getter/setters for 
non-configurable accessors, I guess.


More information about the es-discuss mailing list