Direct proxies update
allen at wirfs-brock.com
Sun Nov 27 16:02:22 PST 2011
On Nov 25, 2011, at 8:29 AM, Tom Van Cutsem wrote:
> 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 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.
too many ways to do the same thing is desirable. We already have a number of reflection functions hung off of Object. Your proposal replicates most of those and adds others as functions in the @reflect module. Such duplication is probably unavoidable if we want to transition from the Object based APIs. But if we also added a mirrors based API that also duplicates some of the same functionality we will have three different ways to do some things. One "old way" and two "two ways". That seems like too many.
> 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:
> 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.
Yes, I thought about this. One way to avoid the per call allocation is for a proxy to keep as part of its state an appropriate mirror instance on the target object. Proxies that need to do mirror based reflection would create the mirror when the target is set. Proxies that don't reflect don't need to capture such a mirror.
> 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.
The difference is that they are now being exposed as general purpose reflection functions rather than being islolated as methods that are port of the Proxy subsystem.
> 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.
I think we should try to minimize reduncency in our API design. Too many ways to do the same thing causes confusion,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss