Le 02/05/2013 08:51, Tom Van Cutsem a écrit :
> 2013/5/1 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130502/ce9d4627/attachment.html>

Le 02/05/2013 08:51, Tom Van Cutsem a ?crit :
> 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.

[1]: https://mail.mozilla.org/pipermail/es-discuss/2011-May/013954.html