<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Forwarder</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=2>Stephen Pair wrote:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> >Great stuff! I'm very excited by your work, especially as a </FONT>
<BR><FONT SIZE=2>> mechanism</FONT>
<BR><FONT SIZE=2>> for delegation. I am </FONT>
<BR><FONT SIZE=2>> >currently using the Trampoline object, that I think you originally</FONT>
<BR><FONT SIZE=2>> developed, Stephen. I am unsure</FONT>
<BR><FONT SIZE=2>> >of how the delegation mechanism would work with this forwarder, so</FONT>
<BR><FONT SIZE=2>> please continue the ramblings at</FONT>
<BR><FONT SIZE=2>> >the bottom. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Thanks! No, I didn't do the trampoline...someone else did (can't</FONT>
<BR><FONT SIZE=2>> remember)...but, I incorporated into a little asynchronous messaging</FONT>
<BR><FONT SIZE=2>> demo that I did.</FONT>
</P>
<P><FONT SIZE=2>Ah yes, so I did get that from you. I also have been working on an asynchronous messaging framework, so I did get the Trampoline idea and the asend protocol from you. I extended the contract somewhat. I wanted to allow asynchronous message sends, with the further constraint that returns or exceptions from that send must return to the sending Process. Thus I have the Trampoline with an AsyncMessageGenerator which creates a QueuedPromise and passes that with the AsyncMessageSend object. Both the send and the return go through the respective queues of the Objects communicating. This is done with secretaries, both a global and background Secretaries. I want to embed all of this into the VM, along the lines of ConcurrentSmalltalk.</FONT></P>
<P><FONT SIZE=2>> >[rob - delegation hooks] </FONT>
<BR><FONT SIZE=2>> >This is where I am a bit confused about how this may work in </FONT>
<BR><FONT SIZE=2>> practice.</FONT>
<BR><FONT SIZE=2>> I believe your usage was to</FONT>
<BR><FONT SIZE=2>> >coalesce the reference to a changable object, which would be</FONT>
<BR><FONT SIZE=2>> polymorphic in protocol, to avoid the </FONT>
<BR><FONT SIZE=2>> >cost of a #become:. Is this right? </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Yes, roughly...I wouldn't think of it as coalescing...there are still</FONT>
<BR><FONT SIZE=2>> two distinct objects, one just delgates everything it receives to the</FONT>
<BR><FONT SIZE=2>> other.</FONT>
</P>
<P><FONT SIZE=2>Ok, but you maintain the same reference externally, even while the implementation of the Forwardee mutates. This is extremely interesting.</FONT></P>
<P><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> >If I were to use a delegation model, or a managed object</FONT>
<BR><FONT SIZE=2>> >model, then I think the forwardee is the delegator or manager. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Actually, this is the opposite of the way I would describe </FONT>
<BR><FONT SIZE=2>> it. I would</FONT>
<BR><FONT SIZE=2>> describe the Forwarder as the delegator, and the forwardee as the</FONT>
<BR><FONT SIZE=2>> delegatee (is that a word?)...I don't really remember what (if any)</FONT>
<BR><FONT SIZE=2>> standard terminology has been established regarding delegation.</FONT>
</P>
<P><FONT SIZE=2>:-) I don't know if that is a word, but I have the wrong idea of a Delegator. Are you saying that it delegates method lookup? </FONT></P>
<P><FONT SIZE=2>More interesting to me are transparent proxies that maintains identity under self reference, forward all messages, and allows me to do management of the message send in a :before and :after sense. I don't want to have duplicate all of the protocol in a surrogate class for the proxied object. This is what I was thinking with the term Managed Objects. This management may include Security checks, faulting, async sending/remote sending and future management.</FONT></P>
<P><FONT SIZE=2>The Trampoline object subclasses from ProtoObject and so there is an identity problem, as well as not always forwarding all message sends. It does this with DNU, so that is the point at which I can do the :before and :after work. It isn't clear to me where I can do this with the Forwarder. I would like to configure the Forwarder with a manager, which could intercept the message send and transform it into a different type of send. </FONT></P>
<P><FONT SIZE=2>The possible solutions I know about are:</FONT>
<BR> <FONT SIZE=2>- Trampoline with a DNU, but the current version doesn't reroute all message sends.</FONT>
<BR> <FONT SIZE=2>- MethodWrappers, I really haven't looked at these, but it doesn't present a new, managed reference.</FONT>
<BR> <FONT SIZE=2>- Forwarder, but I don't see how to activate the Manager</FONT>
</P>
<P><FONT SIZE=2>Perhaps it is a delegator model I am looking for, with your ability to install custom lookup. This may be the managed sending that I want. I will have to read the Self papers and more about AOP. I can sense that maintenance of self and identity would be interesting in this Delegative model.</FONT></P>
<P><FONT SIZE=2><snip></FONT>
<BR><FONT SIZE=2>> I think you've lost me...also the Forwarder would not be used </FONT>
<BR><FONT SIZE=2>> at all in</FONT>
<BR><FONT SIZE=2>> delegation (it can't because because no method will ever be activated</FONT>
<BR><FONT SIZE=2>> for any of its instances)...in my mind delegation requires that you be</FONT>
<BR><FONT SIZE=2>> able to send a message to an object, and receive any messages that are</FONT>
<BR><FONT SIZE=2>> sent to self in the target method. It's kind of like dynamically</FONT>
<BR><FONT SIZE=2>> subclassing the target object, but it only affects the instances</FONT>
<BR><FONT SIZE=2>> involved, it is only in effect for the duration of the </FONT>
<BR><FONT SIZE=2>> delegated message</FONT>
<BR><FONT SIZE=2>> send, and the two objects remain distinct (having separate</FONT>
<BR><FONT SIZE=2>> state...unlike subclassing, in which instances reflect a union of all</FONT>
<BR><FONT SIZE=2>> instance variable in the class and its superclasses).</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> DNU comes into play when a delegated method context sends a message to</FONT>
<BR><FONT SIZE=2>> self, which would get routed back to the delegator...which may not</FONT>
<BR><FONT SIZE=2>> natively understand the message and desires to once again </FONT>
<BR><FONT SIZE=2>> delegate (this</FONT>
<BR><FONT SIZE=2>> is analogous to the the lookup of a method in the superclass chain).</FONT>
<BR><FONT SIZE=2>> Alternatively, the delegator may implement the method, and choose to</FONT>
<BR><FONT SIZE=2>> delegate it, optionally adding behavior of its own (this is </FONT>
<BR><FONT SIZE=2>> analogous to</FONT>
<BR><FONT SIZE=2>> a super send).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Of course, you would need to support additional syntax to generate a</FONT>
<BR><FONT SIZE=2>> "delegated send" bytecode. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> So, having a mechanism to define a custom lookup could be beneficial.</FONT>
<BR><FONT SIZE=2>> You could choose to first do a normal lookup, then try one of several</FONT>
<BR><FONT SIZE=2>> instance variables for potential delegation, or any number of</FONT>
<BR><FONT SIZE=2>> possibilites. I don't think calling back into Smalltalk for </FONT>
<BR><FONT SIZE=2>> that would</FONT>
<BR><FONT SIZE=2>> be an issue...the default case of a normal lookup has to be handled</FONT>
<BR><FONT SIZE=2>> efficiently though. And, you have to be careful not to melt </FONT>
<BR><FONT SIZE=2>> down into a</FONT>
<BR><FONT SIZE=2>> infinte recursion trying to lookup the method lookup method lookup</FONT>
<BR><FONT SIZE=2>> method lookup method lookup method lookup....you get the idea. But, I</FONT>
<BR><FONT SIZE=2>> think if you want the real deal...you have to go all the way to Self.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I haven't experimented with the delegation aspect...so, there may be</FONT>
<BR><FONT SIZE=2>> something in there that blows apart my whole notion of how it might</FONT>
<BR><FONT SIZE=2>> work. I'm going to play around with the forwarding capability for a</FONT>
<BR><FONT SIZE=2>> while first.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> - Stephen</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>- Rob</FONT>
</P>
</BODY>
</HTML>