Function identity of non-configurable accessors
bruant.d at gmail.com
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
>>> 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
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