Most current Proxy-as-implemented test suite?
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?). 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.
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.
What is the most current test suite available for this variant of proxies? So far I have found hg.ecmascript.org/tests/harmony, which seems to be a more recent version of what we are currently using, but has it been superseded by something else?
I have started an unofficial test suite for direct proxies 4. It's incomplete, but if you want to move to direct proxies, that would be a good start I guess. Review the tests before fully trusting them, so far it's been only me working on that.
On Wed, May 1, 2013 at 2:17 PM, David Bruant <bruant.d at gmail.com> wrote:
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?
Sorry, I misspoke. Not modifying the API, but patching/wrapping the Proxy implementation to support other SES features.
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).
I agree that this is what we should be doing. However, we currently have to maintain ES5/3 (our emulation of ES5 on top of browsers that do not implement ES5, or do not do so correctly) which includes an implementation of Proxy. It's less work overall if we don't ditch harmony:proxies until we can also ditch ES5/3.
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.
Indeed.
2013/5/1 Kevin Reid <kpreid at google.com>
What is the most current test suite available for this variant of proxies? So far I have found hg.ecmascript.org/tests/harmony, which seems to be a more recent version of what we are currently using, but has it been superseded by something else?
The test suite you refer to is the first test suite I wrote for the original harmony:proxies. I used it mostly to test the early Mozilla implementation done by Andreas Gal. It wouldn't surprise me if Mozilla extended this test suite to test their implementation more thoroughly. Also, since these proxies are also in v8, perhaps Andreas Rossberg can point you to the test suite used to test v8 proxies.
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 < 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.
On 2 May 2013 08:42, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
2013/5/1 Kevin Reid <kpreid at google.com>
What is the most current test suite available for this variant of proxies? So far I have found hg.ecmascript.org/tests/harmony, which seems to be a more recent version of what we are currently using, but has it been superseded by something else?
The test suite you refer to is the first test suite I wrote for the original harmony:proxies. I used it mostly to test the early Mozilla implementation done by Andreas Gal. It wouldn't surprise me if Mozilla extended this test suite to test their implementation more thoroughly. Also, since these proxies are also in v8, perhaps Andreas Rossberg can point you to the test suite used to test v8 proxies.
The tests I wrote for V8 can be seen here (the 7 files named proxies*):
code.google.com/p/v8/source/browse/branches/bleeding_edge#bleeding_edge%2Ftest%2Fmjsunit%2Fharmony
I believe they are quite a bit more extensive than what's in the Ecma repository. But they are also rather monolithic, and rely on V8's MJSunit test lib.
Le 02/05/2013 08:51, Tom Van Cutsem a ?crit :
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 non-extensible objects. IIRC, trying to change the design of harmony:proxies to be able to represent these (probably started at 1, 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 invariant storage. 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.
On Wed, May 1, 2013 at 11:42 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
2013/5/1 Kevin Reid <kpreid at google.com>
What is the most current test suite available for this variant of proxies? So far I have found hg.ecmascript.org/tests/harmony, which seems to be a more recent version of what we are currently using, but has it been superseded by something else?
The test suite you refer to is the first test suite I wrote for the original harmony:proxies. I used it mostly to test the early Mozilla implementation done by Andreas Gal. It wouldn't surprise me if Mozilla extended this test suite to test their implementation more thoroughly. Also, since these proxies are also in v8, perhaps Andreas Rossberg can point you to the test suite used to test v8 proxies.
FYI, I've gone with the version I linked above — it appears to be sufficient for our immediate technical needs, and as David Bruant also said, it is better not to spend too much effort on maintaining an expected-to-be-obsolete API.
2013/5/2 David Bruant <bruant.d at gmail.com>
IIRC, trying to change the design of harmony:proxies to be able to represent these (probably started at [1], 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 invariant storage. Direct proxies emerged out of the idea of merging the target from the forwarding proxy use case and the "invariant storage".
Yes, that's a fairly accurate history.
In any case, harmony:proxies have limitations apparently inherent to their design, hence moving away from them.
The limitation was indeed that they couldn't represent non-extensible/non-configurable invariants without some extra hidden storage. Direct proxies make that storage explicit as the target object.
In Caja we have several uses for Proxies, some of which involve reimplementing or modifying the Proxy API. We are currently following the original harmony:proxies (rather than direct or notification proxies) since that's what is available in browsers.
What is the most current test suite available for this variant of proxies? So far I have found hg.ecmascript.org/tests/harmony, which seems to be a more
recent version of what we are currently using, but has it been superseded by something else?