Proxies with State

Cormac Flanagan cormac at
Thu Jun 2 16:41:38 PDT 2011

Here's one possible implementation strategy for proxies that does not
require any changes to the language semantics yet still could deal
with the space overhead concern of having separate proxy + handler
objects. This idea is very preliminary, and may have holes...

Normally, a call to Proxy.create(handler) creates a proxy object that
has a reference to the handler, resulting in two objects (the proxy
and the handler), both of which may be long-lived.

Alternatively, we could
1. copy the bits of the handler state into the proxy object
2. convert the original handler in to a "forwarding object" that
accesses/updates the corresponding bits of the proxy object
3. two forwarding objects are considered equal if the forward to the
same proxy objects.
This change in representation should not result in observably
different behavior.

Once this representation change is accomplished, the forwarding
objects have no state or identity. So there is no need for the proxy
to maintain a reference to the handler forwarding object - it can
instead recreate an equivalent forwarding object each time a proxy
trap is called. These reallocated forwarding objects are likely to be
short-lived, and live only for the duration of the trap call.

Clearly, there is some additional implementation complexity here, but
something like this might allow us to represent a proxy/handler pair
using only one long-lived object, rather than two, while avoiding any
additional language complexity.

      - Cormac

On Tue, May 31, 2011 at 8:46 PM, Brendan Eich <brendan at> wrote:
> On May 31, 2011, at 4:57 PM, Cormac Flanagan wrote:
>> One possible concern with proxies is the overhead of separate proxy
>> and handler objects, and trap methods that likely close over a backing
>> object.
> Or weakmap proxies to backing objects.
>> This concern would be exacerbated in the case of value
>> proxies, where we might want millions of complex number proxies, and
>> also came up in the discussion of the Observer use case last week.
> The strawman at addresses this by specifying a Proxy.createValue function taking a StructType descriptor as its last argument.
> This is a targeted API, not for all use-cases but specifically for the one you cite: primitive values with efficiently packed structured binary data representations and operator methods.
>> It seems it would be nice to allow proxy objects to have some state.
> I think Proxies hit a sweet spot by isolating handler and proxy apart from the introduction in Proxy.create{,Function}. Trying to overload them to handle state (especially efficient, co-allocated binary data) is too much.
> /be

More information about the es-discuss mailing list