Hi,

I've been working on implementing Notification proxies as originally
proposed by Dean Tribble on this list [1] and then later expanded upon [2].

In a nutshell, their history is somewhat as follows:
1) original proxies could not emulate non-extensible objects or objects
with non-configurable properties
2) direct proxies, by directly wrapping a specific target object, allow
safe emulation of such objects/properties but at the expense of complex
invariant checks.
3) notification proxies aim to get rid of invariant checks by only
notifying the handler that an operation was performed on the proxy, and
then automatically forwarding to the real target. The handler doesn't get
to influence the result of an intercepted operation. Traps essentially
become just notification callbacks (although the notification is
synchronous).

See the readme for details:
https://github.com/tvcutsem/harmony-reflect/tree/master/notification

There's also two examples: a generic logging proxy that just logs all
intercepted operations, and a revocable reference, expressed as a
notification proxy.

For these two examples, notification proxies work out very well. They're
even simpler than direct proxies because there's no need to manually
forward.

The notification proxy implementation (on top of old proxies) is also
significantly simpler compared to direct proxies, so notification proxies
are probably a lot simpler to specify as well.

The remaining challenge with notification proxies is how to implement
proxies where always forwarding all operations automatically does not make
sense. Examples include membranes (need to wrap the result), and perhaps
self-hosted exotics that aren't backed by any real "target". I haven't yet
gotten around to implementing those. If anyone is willing to give it a try
in the mean time, this would lead to valuable feedback.

I realize we're close to the ES6 deadline and this would be a big change to
proxies. At this time I'm not seriously proposing notification proxies as
an alternative to direct proxies. We need more experience with them first.

Cheers,
Tom

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026587.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026589.html
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to