Le 20/12/2012 13:18, Tom Van Cutsem a écrit :
2012/12/20 David Bruant <[email protected] <mailto:[email protected]>>
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 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
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!
1) http://davidbruant.github.com/iframeProxyIssueDemo/
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:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027180.html
& https://mail.mozilla.org/pipermail/es-discuss/2012-December/027183.html
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".
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
