Re: Proxies with State

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

Re: Proxies with State

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

Re: Proxies with State

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

Re: Proxies with State

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

Proxies with State

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 discussi