Function identity of non-configurable accessors

Tom Van Cutsem tomvc.be at gmail.com
Thu Dec 20 04:18:41 PST 2012


2012/12/20 David Bruant <bruant.d at gmail.com>

>  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) {
  // I can now safely assume that obj.foo 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 obj.foo will actually update the
property
}

If I understand correctly, the current reality is that there exist DOM
properties that violate the configurable:true contract, but there are not
(yet?) DOM properties that violate the configurable:false contract.

If that is true, then making the accessors on WindowProxy be
configurable:true would continue the current practice of violating the
configurable:true contract. Not saying this is good or bad, just an
observation.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121220/e7de8043/attachment.html>


More information about the es-discuss mailing list