Direct proxies update
Tom Van Cutsem
tomvc.be at gmail.com
Thu Nov 24 13:29:20 PST 2011
2011/11/24 Allen Wirfs-Brock <allen at wirfs-brock.com>
> If we are going to have a @reflection module that is of broader
> applicability then just writing proxy handlers I'd like us to consider a
> Mirrors style API. Otherwise I'm a concern will continue to have a
> proliferation of reflection APIs as we move beyond Proxies into other use
I'm not sure I understand. Additional reflection functionality can easily
be added to the @reflect module. It need not be exclusive to Proxies.
> At https://github.com/allenwb/jsmirrors is a first cut of a mirrors API
> as a finished product but it could be a starting point for this sort of
> At the core is a root question whether we want to expose a functional or
> object-oriented API for reflection functionality. These are two different
> styles each of which is probably favored by a different subset of our user
> community. I suspect that everyone knows which sub-community I align with.
> The main argument for the OO style is that it allows creation of client
> code that can be oblivious to the underlying implementation of the API.
> The allows for more flexible client code that has greater potential for
I'm sympathetic to mirror-based APIs myself. However, note that a
mirror-based API would require an extra allocation as opposed to the
// Proposed API:
// Mirror-style API:
In the common case of forwarding an intercepted operation to a target
object, a mirror API requires the allocation of a mirror on the target,
just to be able to invoke the proper method, only for that mirror to be
discarded right away.
I don't see mirrors as being in conflict with this API though. Mirrors can
be perfectly layered on top.
> I haven't pushed for adopting mirrors into ES.next because I thought we
> already had too much on the table. However, if we are going to create new
> reflection APIs then I think we should carefully consider the pros and cons
> of the mirrors style.
I don't understand why you think of the @reflect module as a "new"
reflection API: all of the functionality in it (save for the
VirtualHandler) was already present in the original Proxy proposal, where
most of the Reflect.* methods were methods on the default
ForwardingHandler. Putting them in a separate @reflect module seems the
right thing to do now that we have a module system.
I'm sympathetic to mirrors, but I don't think it's an either/or story. A
mirror-based API can be layered on top of the standard @reflect module. I'm
not sure it needs to be standardized now though: the current API provides
the minimum required functionality with minimum overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss