Direct proxies update

Allen Wirfs-Brock allen at
Mon Nov 28 16:23:17 PST 2011

On Nov 28, 2011, at 7:04 PM, Tom Van Cutsem wrote:

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

I agree.  However, it would be desirable to minimize the number of additional layers evolutionary growth.

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

The same way it knows which functions it needs to call.  It is either hard coded or parameterized.  For example:

       Proxy(target, new WhateverHandler(target))

if Whatever handler needs to create and retain a particular kind of mirror it does so:

      function WhateverHandler(target) {
         this.mirror = NativeReflectionMirror.on(target);

or the responsibility for knowing what kind to mirror to use might reside in the Proxy factory:
  Proxy(surrogateTarget, new HandlerForMirror(RemoteMirror.for(remoteID))

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

Because of the invariant validation mechanism, the target needs to be a direct reference to a native object rather than a mirror.

If I understand the general usage model, then in the general case it may not be as lean as Proxy(target,handler) regardless of whether Mirrors are involved.  If the handler needs to retain any per proxy instance state then a new handler is going to have to be instantiated for each Proxy instance in order to capture that state. Proxy(target, new MyHandler(args))

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

More information about the es-discuss mailing list