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

Tom Van Cutsem at
Wed Nov 28 13:09:24 PST 2012

2012/11/26 Dean Tribble <dtribble at>

> On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem < at>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
- membranes
- higher-order contracts

Before-style wrapping:
- revocable references

What else?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list