Le 02/05/2013 08:51, Tom Van Cutsem a écrit :
2013/5/1 David Bruant <[email protected] <mailto:[email protected]>>
If anything, I would recommend to move away from the initial proxy
design for Caja, because the harmony:proxies API is meant to never
see light in the spec (and should probably be removed from
Firefox). Among other things, harmony:proxies would have requires
to ~double the memory to check ES5 invariants regarding
non-extensibility and non-configurability. Direct proxies make the
check on the target (and make the forwarding proxy first-class
which enables optimizations that probably couldn't have been
possible in the previous design). Notification proxies guarantee
the invariants by design, but force a slightly different
programming style.
Why would old harmony:proxies require twice the memory to check ES5
invariants? Old harmony:proxies couldn't represent non-configurable
properties or non-extensible objects. There were no invariants to
check, so also no invariant checking overhead.
True, they couldn't represent non-configurable properties and
non-extensible objects.
IIRC, trying to change the design of harmony:proxies to be able to
represent these (probably started at [1], also motivated by arrays
length property) led to listing invariants (eternal/momentary) and then
led to the idea of a per-proxy storage to remember which invariants
should be enforced. But for the degenerate case of a forwarding proxy
(frozen object), this would have resulted in pretty much duplicating the
needed memory. One fold for the object itself, the other for the
invariant storage.
Direct proxies emerged out of the idea of merging the target from the
forwarding proxy use case and the "invariant storage".
In any case, harmony:proxies have limitations apparently inherent to
their design, hence moving away from them.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/013954.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
