Function identity of non-configurable accessors

David Bruant bruant.d at
Thu Dec 20 05:59:34 PST 2012

Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
> 2012/12/20 David Bruant <bruant.d at <mailto:bruant.d at>>
>     Le 20/12/2012 09:02, Tom Van Cutsem a écrit :
>>     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
> I think the general issue (of which we are discussing a tiny specific 
> case) is the following:
> Mark's position is that configurable:true implies *no* formal contract 
> on the part of the advertising object. A property advertised as 
> configurable may or may not behave as configurable. On the other hand, 
> configurable:false implies a formal contract, and one for which we go 
> through great pains so that even proxies can't violate the contract.
> 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.

>   // I can now safely assume that will never change
> }
> Allen's position is that this is a double standard. I think he wants 
> to support reasoning about code of the form:
> if (Object.getOwnPropertyDescriptor(obj, "foo").configurable) {
>   // I can now safely assume that updating will actually 
> update the property
> }
> If I understand correctly, the current reality is that there exist DOM 
> properties that violate the configurable:true contract
Not that I am aware of. But Mark repeated suggestion was to go in that 
direction and I agree because of the next point:

> but there are not (yet?) DOM properties that violate the 
> configurable:false contract.
Quite the opposite, there are 3 of them just for WindowProxy!
View source and open the console to see the configurable:false. I see 
the violation in Firefox and Chrome and this violation is what the 
current WebIDL spec expects.
(side note: I have the proxy invariants enforcement rules hardwired in 
my brain because I have a weird feeling each time I open the page and 
see the violation; a little voice telling me "something is not right in 
this code and what's logged")
2) var/function global declarations. See: 
3) WebIDL requires [Unforgeable] to be non-configurable meaning that 
getter/setter identity has to be preserves which can lead to a 
capability leak. WebIDL currently requires web browsers to leak 
capabilities or violate the getter/setter identity requirement.

configurable:false violation are the ones I have been chasing, because 
they go against the ES5 invariants and consequently can't be emulated 
with proxies.

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.

The current solutions are:
1) throw on Object.defineProperty with configurable:false
2) configurable:true
3) Still in debate
3.1) configurable:true
3.2) configurable:false with deeply frozen "null realm" getters/setters

> If that is true, then making the accessors on WindowProxy be 
> configurable:true would continue the current practice of violating the 
> configurable:true contract.
It would actually be the first configurable:true convention "violation".

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

More information about the es-discuss mailing list