Direct proxies update

Tom Van Cutsem at
Mon Nov 28 00:04:45 PST 2011

2011/11/28 Allen Wirfs-Brock <allen at>

> 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.

The duplication of existing Object.* reflection methods is unfortunate, but
a direct consequence of evolutionary growth. I don't have any solutions for
avoiding it.

> 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.

That would work, although how does the proxy know which "mirror factory" to
use? (if it uses the "default" one, there's no polymorphism and you might
as well use the Reflect.* API)

I guess one could pass the proxy a mirror to the target, rather than a
direct reference to the target itself. It still isn't as 'lean' though:
Proxy(target,handler) vs. Proxy(Mirror.on(target), handler)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list