Most current Proxy-as-implemented test suite?
Tom Van Cutsem
tomvc.be at gmail.com
Wed May 1 23:51:34 PDT 2013
2013/5/1 David Bruant <bruant.d at gmail.com>
> Le 01/05/2013 22:26, Kevin Reid a écrit :
> In Caja we have several uses for Proxies, some of which involve
>> reimplementing or modifying the Proxy API.
> Out of curiosity, how are you modifying it? for which use case?
> We are currently following
>> the original harmony:proxies (rather than direct or notification
>> proxies) since that's what is available in browsers.
> Firefox implements and shipped direct proxies as part of Firefox 18 .
> At this occasion, I moved the old proxy design MDN documentation in its own
> page .
> Last I heard, V8 was waiting on the spec to stabilize before moving
> forward on implementation .
> The API on the table for now is direct proxies. Notification proxies are
> being discussed but haven't met consensus yet (are there news on this
> front, TC39ers?).
On the agenda for the May meeting.
I've meant to post about my experiments with them earlier, but haven't
gotten to it yet. Sneak preview: I've implemented membranes using
notification proxies as well as using direct proxies. I still need to run
some benchmarks to compare both. Source for notification proxies &
membranes available at <
> 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.
> Tom Van Cutsem wrote a direct proxies shim that runs on top of current
> browser implementations . If you want to move to direct proxies, it
> might be something to consider.
Yes, I'm still maintaining this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss