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

Sam Tobin-Hochstadt samth at ccs.neu.edu
Mon Nov 26 05:30:46 PST 2012


On Mon, Nov 26, 2012 at 3:36 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
>
>> If indeed both kinds of proxy are useful and direct proxies are more
>> powerful, then why not only have a foundational direct proxy API and
>> implement a tool type NotificationProxy that is based on that API.
>
> An interesting question I still haven't found a satisfying answer to is: is
> the additional power of current proxies useful? and worth the cost? Because
> the current freedom of proxies is the root cause of invariant checks that
> even good proxy citizens have to pay.

At a minimum, the direct proxies allow remote objects and other
entirely virtual objects to be implemented with no allocation
overhead.  In contrast, notification proxies require allocation
proportional to the size of the remote object being proxied. In
Racket, whose chaperone system has some of the flavor of notification
proxies, this makes remote objects more costly and difficult to
implement.  This is less of a problem in Racket, since the primary use
case for chaperones is the implementation of contracts, and virtual
objects would usually be handled differently.

--
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list