Function identity of non-configurable accessors

David Bruant bruant.d at
Thu Dec 20 10:41:15 PST 2012

Le 20/12/2012 18:51, Tom Van Cutsem a écrit :
> 2012/12/20 David Bruant <bruant.d at <mailto:bruant.d at>>
>     Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
>>     Mark supports this view to enable reasoning about code of the form:
>>     if ( ! Object.getOwnPropertyDescriptor(obj, "foo").configurable) {
>     host objects (or proxies) could omit .configurable or make it any
>     other falsy value. The test is rather:
>         if (Object.getOwnPropertyDescriptor(obj, "foo").configurable
>     === false) {
>     It's a nit, but an important one.
> We've taken care that Object.getOwnPropertyDescriptor actually 
> normalizes and completes the standard attributes, so proxies at least 
> cannot do that.
Good point. I had forgotten that part.

>     WindowProxy would violate both contracts when reflecting
>     var/function globals and [Unforgeable]. These properties can't be
>     configurable:false because they may disappear and they don't
>     respect "Allen's configurable:true contract", because they can't
>     be removed using 'delete'.
>     The WindowProxy de-facto standard does not correspond to the
>     configurable true or false behavior, so one contract has to be
>     violated.
>     Because of the importance of invariants, it has to be
>     configurable:true. But this contract is not a big deal because
>     it's more a convention that a contract. Neither ES5 host objects
>     nor proxies are expected to anything regarding configurable:true.
>     All objects defined in the ES spec are expected to follow the
>     contract defined by the semantics of its internal methods.
> Generalizing from this specific example again, we have the following 
> facts:
> 1) proxies are restricted so that they can only emulate objects that 
> uphold ES5 invariants
> 2) DOM objects are weird objects that don't always act like ES5 objects.
> 3) Some DOM objects don't uphold ES5 invariants.
If I had to guess, I would say that the reason is that the invariants 
are a not well-known part of the ES5 spec and that before I raised the 
concerned, no one had thought about what happens to the WindowProxy 
object of an iframe when navigation occurs.
Since WebIDL is not widely deployed (IE9 and probably 10 conform well, 
Firefox's woking on it. I don't know for the rest), it's still easy to 
change the spec and implementations.

> 4) an important use case for proxies is to be able to self-host DOM 
> objects.
> Putting these together, the inevitable conclusion is that there are 
> some DOM objects that can't be emulated by proxies.
Wasn't it a goal of the Proxy API? It seems that we're only a couple of 
booleans away from achieving it (besides document.all being falsy).

> What to conclude from that?
> a) lift the restrictions on proxies. This is the same as saying: ES6 
> has no universal invariants (it has some invariants that apply to 
> normal objects, but none that apply to normal and exotic objects 
> alike) One could introduce an Object.isExotic predicate that answers 
> true on host and proxy objects, allowing code to "protect" itself from 
> these objects. One issue is that extant ES5 code does not protect 
> itself in this way.
> b) make the consensus that in a proxy-emulated DOM, it's OK for the 
> emulation to be imperfect when it comes to invariants. One could argue 
> that having the emulation be imperfect for these cases is not that big 
> a deal, especially since the incompatibilities involve corner cases 
> with little cross-browser compatibility in the first place.
In both cases, you're going to make Mark angry ;-)
If any of these 2 ideas were considered, I would go further and add an 
Object.doesNotConformToInvariants sort of test so that only one test can 
determine whether an object conforms to invariants or not. Bouncing on 
Mark's point about building new invariant-violating objects when you 
have access to existing ones, if a proxy has a target returning false 
for this test, so would the proxy.

I have to admit, I like the idea of eternal invariants that apply to 
every single ECMAScript object and the set we currently have is small 
enough to be not that intrusive.

> Any other options?
Change WebIDL/WindowProxy to conform to the ES5 invariants, which they 
should have from the start and still can because WebIDL has a low adoption.

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

More information about the es-discuss mailing list