2012/12/20 David Bruant <bruan...@gmail.com>
> 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.
>
> 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:
>
By the configurable:true contract, I also meant the "deletable" part, which
as Brandon points out, is violated in practice.
> 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")
>
:-)
> 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.
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.
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.
Any other options?
Cheers,
Tom
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
