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(handler) creates a proxy object that has a reference to the handler, resulting in two objects (the proxy and the handler), both of which may be long-lived. Alternatively, we could 1. copy the bits of the handler state into the proxy object 2. convert the original handler in to a "forwarding object" that accesses/updates the corresponding bits of the proxy object 3. two forwarding objects are considered equal if the forward to the same proxy objects. This change in representation should not result in observably different behavior. Once this representation change is accomplished, the forwarding objects have no state or identity. So there is no need for the proxy to maintain a reference to the handler forwarding object - it can instead recreate an equivalent forwarding object each time a proxy trap is called. These reallocated forwarding objects are likely to be short-lived, and live only for the duration of the trap call. Clearly, there is some additional implementation complexity here, but something like this might allow us to represent a proxy/handler pair using only one long-lived object, rather than two, while avoiding any additional language complexity. - Cormac On Tue, May 31, 2011 at 8:46 PM, Brendan Eich <bren...@mozilla.com> wrote: > 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 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. > > The strawman at http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies > addresses this by specifying a Proxy.createValue function taking a > http://wiki.ecmascript.org/doku.php?id=strawman:binary_data StructType > descriptor as its last argument. > > This is a targeted API, not for all use-cases but specifically for the one > you cite: primitive values with efficiently packed structured binary data > representations and operator methods. > > >> It seems it would be nice to allow proxy objects to have some state. > > I think Proxies hit a sweet spot by isolating handler and proxy apart from > the introduction in Proxy.create{,Function}. Trying to overload them to > handle state (especially efficient, co-allocated binary data) is too much. > > /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
