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

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Nov 28 21:23:18 PST 2012


On Nov 28, 2012, at 1:09 PM, Tom Van Cutsem wrote:

> 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
-virtualizing a backing store as properties. 
-supported extended property attributes
> 
> Around-style wrapping (need to be able to change the result of an operation):
> - membranes
> - higher-order contracts

introducing new inheritance schemes, eg, multiple inheritance

> 
> Before-style wrapping:
> - revocable references

After-style

a "doesNotUnderstand" wrapper -- run the operation, but if the result is undefined check if missing property and if so, call  DNU handler


> 
> What else?
> 
> Cheers,
> Tom
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121128/12a7d3ff/attachment-0001.html>


More information about the es-discuss mailing list