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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
