Most current Proxy-as-implemented test suite?
bruant.d at gmail.com
Thu May 2 05:55:47 PDT 2013
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
IIRC, trying to change the design of harmony:proxies to be able to
represent these (probably started at , 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss