Function identity of non-configurable accessors
Brendan Eich
brendan at mozilla.com
Sat Dec 15 13:20:58 PST 2012
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
More information about the es-discuss
mailing list