2011/11/24 Allen Wirfs-Brock <[email protected]> > > 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 > cases. >
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 > that I threw together earlier this year for JavaScript. I don't hold it up > as a finished product but it could be a starting point for this sort of > design. > > 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 > reuse. > 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: // Proposed API: Reflect.has(object, name) // Mirror-style API: Mirror.on(object).has(name) 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. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
