Proxies with State

David Bruant david.bruant at
Wed Jun 1 01:23:23 PDT 2011

Le 01/06/2011 01:57, Cormac Flanagan a écrit :
> 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.
In a previous discussion [1] (that I forked at [2]), we've been 
discussing how proxy state could be handled to be made available. One 
interesting idea (actually it was in Tom and Mark proposal [3] all 
along) was that the handler could have all methods in its prototype and 
its state at the "own properties level". Providing a direct access to 
this own level could be a way to achieve what you want.

I am under the impression that your understanding of "state" is that it 
is a (regular) object. It is not necessarily. Proxies provide an 
abstraction of something that looks like an object but may not behave 
like so. See my experiment at [4]. The proxy state is not an object in 
the ECMAScript sense.
It's in the proxy core design to trap operations without the ability to 
"bypass" the traps. However, as said above, you, as a library writer, 
can provide access to your internal proxy state. But it must be your 
decision, not something proxy users should be able to do natively.

> This might allow us to proxify existing objects to attach an Observer
> without introducing much additional, per-object overhead.
As said in the previous thread about Observers, proxies may not be the 
right thing to implement them (even though it's perfectly possible). A 
dedicated API would be much more efficient (in terms of performance) and 
relevant in my opinion. There wouldn't be any overhead.



More information about the es-discuss mailing list