Function identity of non-configurable accessors

[Brendan Eich]

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