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 [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 <
https://github.com/tvcutsem/harmony-reflect/tree/master/notification>.


> 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.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130502/5fe7cc4c/attachment.html>


More information about the es-discuss mailing list