Le 20/12/2012 18:51, Tom Van Cutsem a écrit :
2012/12/20 David Bruant <[email protected] <mailto:[email protected]>>
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
