On Nov 28, 2011, at 7:04 PM, Tom Van Cutsem wrote:
> 2011/11/28 Allen Wirfs-Brock <[email protected]>
> 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))
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
