Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

Tom Van Cutsem tomvc.be at gmail.com
Wed Nov 28 13:09:24 PST 2012


2012/11/26 Dean Tribble <dtribble at gmail.com>

> On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem <tomvc.be at gmail.com>wrote:
>
>> Thanks for spelling out these examples. While they still don't feel like
>> actual important use cases to support, they give a good flavor of the kinds
>> of compromises we'd need to make when turning to notification-only proxies.
>>
>
> I agree. My usual expectation for proxies is to support remote and
> persistent objects. While supporting other scenarios is great, usually
> that's incidental.  Is there a broader list of aspirations for proxies? or
> is this just a "all else being equal it would be good if we can do this"?
>

Let's talk about aspirations for proxies. It will help us set priorities.

First, some terminology (originating from CLOS, the "mother of all MOPs" ;-)
CLOS method combinations allow a composer to distinguish between "before",
"after" and "around"-style composition:
- "before"-style wrapping gives you only the ability to get notified before
an operation happens. You can abort, but not change, the result of the
operation. This is what notification-proxies offer.
- "after"-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the "after"-wrapper may or may not
get to see the outcome of the operation, and may or may not change the
final outcome passed on to clients.
- "around"-style wrapping is the most general and allows the composer to
decide if and when to forward, and what result to return. It subsumes
before/after wrapping. This is what direct proxies currently provide.

As far as I can tell, virtual object abstractions like remote/persistent
objects require "around"-style wrapping, because there's otherwise no
meaningful target to automatically forward to.

Here's a list of use cases that I frequently have in mind when thinking
about proxies, categorized according to whether the use case requires
before/after/around wrapping:

Virtual objects, hence "around"-style:
- self-hosting "exotic" objects such as Date, Array (i.e. self-host an
ES5/ES6 environment)
- self-hosting DOM/WebIDL objects such as NodeList

Around-style wrapping (need to be able to change the result of an
operation):
- membranes
- higher-order contracts

Before-style wrapping:
- revocable references

What else?

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


More information about the es-discuss mailing list