Most current Proxy-as-implemented test suite?

Tom Van Cutsem at
Wed May 1 23:51:34 PDT 2013

2013/5/1 David Bruant <bruant.d at>

> 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 [1].
> At this occasion, I moved the old proxy design MDN documentation in its own
> page [2].
> Last I heard, V8 was waiting on the spec to stabilize before moving
> forward on implementation [3].
> 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 [4]. 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...
URL: <>

More information about the es-discuss mailing list