Proxies with State
david.bruant at labri.fr
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  (that I forked at ), 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  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 . 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