Proxies with State

Cormac Flanagan cormac at
Tue May 31 17:09:17 PDT 2011

There are two problems with this initial idea.
- One downside is that there are problems when attempting to proxify a proxy.
- Second, accesses to Proxy.untrappedGetOwnPropertyDescriptor(proxy,
name), etc. are verbose and ugly.

A possible workaround is
- each object has an ordered list of proxies (allowing multiple
proxies on an object)
- each handler is passes a 'backing object'  o -- essentially a
temporary proxy that provides convenient access (via o.x etc) to the
state of the underlying object, or to the 'view' of that object as
provided by the next proxy in the proxy chain.

More complex that the current proxy proposal, certainly, but
potentially with a smaller space footprint.

On Tue, May 31, 2011 at 4:57 PM, Cormac Flanagan <cormac at> 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. 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.
> It seems it would be nice to allow proxy objects to have some state.
> Since accesses to the proxy would trap to the handler, we need an
> alternative way for the handler to access the proxy state, perhaps
> Proxy.untrappedGetOwnPropertyDescriptor(proxy, name), etc.
> This might allow us to proxify existing objects to attach an Observer
> without introducing much additional, per-object overhead.
> - Cormac

More information about the es-discuss mailing list