Le 15/12/2012 22:26, Brandon Benvie a écrit :
Is there any leak if you set the accessor functions to have a null [[Prototype]] and to have no non-primitive properties?
There isn't. That would be the super-minimal "null realm" solution.
David
On Sat, Dec 15, 2012 at 4:20 PM, Brendan Eich <[email protected] <mailto:[email protected]>> wrote:David Bruant wrote: 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. Oh sure -- that goes without saying (or so I thought when I wrote it :-P). 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. Yes, so to avoid the "Ice-9" problem, these would have to bottom out in a "null realm" where everything is frozen: Function.prototype, Object.prototype, anything else required (is anything else required for function objects to be deeply frozen?). Or there are probably other things like comparing iframes contentWindow.Function.prototype objects over time (when changing src) that wouldn't be compatible. If you buy the "null realm" idea, the only breaking change would be if someone could extract the get or set function via __lookupGetter__/__lookupSetter__ or the ES5 standard forms, inspect them and find the current window's realm built-ins. Or monkey-patch the current realm's built-in Function.prototype or Object.prototype and expect those properties to be inherited by the get and set functions. But this seems like something we could get away with breaking, maybe. Back to the idea of reflecting different getter/setters for non-configurable accessors, I guess. Let's talk about deep-freezing and the null realm more. /be _______________________________________________ es-discuss mailing list [email protected] <mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
