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 <cor...@cs.ucsc.edu> 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 > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
