Function identity of non-configurable accessors

David Bruant bruant.d at
Sat Dec 15 14:44:57 PST 2012

Le 15/12/2012 22:20, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 15/12/2012 19:11, Brendan Eich a écrit :
>>> 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?).
A frozen Object.prototype means a non-deletable __proto__, but it could 
be omitted, I guess (it's of no use anyway).
'arguments' and 'caller' probably need to be poisoned regardless of 
strictness in "null realm" (maybe it's already the case in WebIDL?)
The rest of the deeply freezing involves a bunch of stateless functions.

>> 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.
Related to your last point, instanceof Function and instanceof Object do 
not work as people would expect (unless they're aware of "null realm"). 
Not a huge deal, bur worth mentioning.

> But this seems like something we could get away with breaking, maybe.
My least favorite solution because it creates a weird special case, but 
it seems workable indeed.


More information about the es-discuss mailing list