2013/5/1 David Bruant <bruan...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
