Function identity of non-configurable accessors

David Bruant bruant.d at gmail.com
Wed Dec 19 09:03:57 PST 2012


Le 19/12/2012 17:34, Brandon Benvie a écrit :
> Also note that none of these properties are currently accessors so no 
> one has come to rely on being able to extract their getters. So 
> introducing them with neutered accessors would not have an impact on 
> existing code.
I fully agree. I wasn't really worried about backward compat.

> On Wednesday, December 19, 2012, Brandon Benvie wrote:
>
>     It only has to be a handful of accessors, no? I was thinking
>     basically of just the few things on the global object that need
>     this treatment. location, document, window, navigator, maybe a few
>     others?
>
Very good point.
We're not redefining what [Unforgeable] means, but only what it means 
for WindowProxy objects, so that's very few properties in the end.

>     And location is the only one with a setter, so we're mostly just
>     talking about getters on the global object. Since it's the global
>     object, you could just call the getter directly and `this` will
>     implicitly be the correct receiver when called inside the context.
>
I always use strict mode, so it wouldn't work for me. But since these 
getter/setter are special, I wouldn't be shocked if they were bound 
functions.

>     So the remaining situations in which it's difficult are in the
>     parent frame when you want to do this one of the handful of
>     properties that have this treatment.
>
>     An option that might have uses in other places as well is a kind
>     of primitive version of call, bind, and apply that have the null
>     prototype, frozen treatment. They could be singletons over the
>     entire runtime, across realms, and be attached to any function in
>     any realm (including these accessors) without leaking anything.
>
I think that was what Brendan called "null realm". It has the problem 
that if someone adds new things to Function.prototype or 
Object.prototype, your "null realm" getters/setters wouldn't benefit 
from it.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121219/cc2a09b4/attachment.html>


More information about the es-discuss mailing list