Function identity of non-configurable accessors

David Bruant bruant.d at
Thu Dec 20 02:49:55 PST 2012

Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
> 2012/12/19 David Bruant <bruant.d at <mailto:bruant.d at>>
>     Le 19/12/2012 17:34, Brandon Benvie a écrit :
>>         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.
> Is that really a problem though?
I don't know. I was just repeating the main argument against this idea.

Historically, the ECMAScript representation of browser APIs was probably 
the least interoperable part of the web platform and certainly still is. 
Open and click anywhere, it 
should visualize a click event object. The result is *very* different in 
the latest Chrome, Firefox, Opera and IE (I haven't tested Safari but I 
assume it's the same than Chrome). There are good reasons for this (lack 
of spec initially then software architecture issues).
Web devs have written at length about the fact that extending the DOM 
was a bad idea [1].

But let's project ourselves in a world of WebIDL compliant browsers and 
Suddenly, extending the ECMAScript environment is safe (collision-free) 
with unique symbols and extending the DOM is both safe and reliable 
(thanks to WebIDL-compliance).
Will special-casing WindowProxy [Unforgeable] getters/setters undermine 
the possibilities of this world? I cannot tell. I'm too used to the 
current world where extending the language is socially unacceptable.

I'm not worried about backward-compat (because as you and Brandon said, 
it's not a problem). I'm rather worried about potential forward-compat 
configurable:true seems to be more future-friendly.

> I think I'm leaning towards non-configurable accessors with 
> deep-frozen (null-realm) getter/setter functions.
Brandon's point about the fact that it really is the matter of a few 
properties made me reconsider my position. I'm between deeply-frozen and 
configurable:true and can't make up my mind :-s


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list