<!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>
<P><FONT SIZE=2>Stephen,</FONT>
</P>
<P><FONT SIZE=2>Great stuff! I'm very excited by your work, especially as a mechanism for delegation. I am currently using the Trampoline object, that I think you originally developed, Stephen. I am unsure of how the delegation mechanism would work with this forwarder, so please continue the ramblings at the bottom.</FONT></P>
<P><FONT SIZE=2>comments below...</FONT>
</P>
<BR>
<P><FONT SIZE=2>Anthony Hannan wrote:</FONT>
</P>
<P><FONT SIZE=2>>Stephen Pair <spair@advantive.com> wrote:</FONT>
<BR><FONT SIZE=2>>> We must ensure that all references to self in the methods of a </FONT>
<BR><FONT SIZE=2>>> forwardee object are actually referring back to the instance of the </FONT>
<BR><FONT SIZE=2>>> forwarder (thus,references to the forwardee can be controlled).</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>I assume your only doing this for identity since obviously the message</FONT>
<BR><FONT SIZE=2>sends will come back to the </FONT>
<BR><FONT SIZE=2>>same forwardee. But what about (Forwarder on: anObject) == anObject?</FONT>
<BR><FONT SIZE=2>It will return false. </FONT>
<BR><FONT SIZE=2>>Changing identity just in the delagated method is not good enough.</FONT>
</P>
<P><FONT SIZE=2>[Stephen said:..]</FONT>
<BR><FONT SIZE=2>Correct...however, for my purpose, it is good enough. I'm only</FONT>
<BR><FONT SIZE=2>maintaining references to the forwarder and the only reference to the</FONT>
<BR><FONT SIZE=2>real object is in the forwarder. If you have a reference to the</FONT>
<BR><FONT SIZE=2>forwarder, why would you ever need to keep a reference to the real</FONT>
<BR><FONT SIZE=2>object, except in the forwarder.</FONT>
</P>
<P><FONT SIZE=2>[rob - identity between forwarder and forwardee]</FONT>
<BR><FONT SIZE=2>Should they be identical? I imagine it would depend on the aspect of identity one is interested in. I agree that it is confusing to think of this identity comparison between a mixed aspect/proxification of the core object.</FONT></P>
<P><FONT SIZE=2><big snip></FONT>
</P>
<P><FONT SIZE=2>[Stephen said:..]</FONT>
<BR><FONT SIZE=2>Also I think this design also allows for delegation...all that's needed</FONT>
<BR><FONT SIZE=2>is a delegated send bytecode and/or primitive. The forwarder is a</FONT>
<BR><FONT SIZE=2>delegator (but it always blindly delegates everything it receives).</FONT>
<BR><FONT SIZE=2>But, delegation would be fairly in-efficient in this design because you</FONT>
<BR><FONT SIZE=2>would need to do an custom message look up and delegation in</FONT>
<BR><FONT SIZE=2>#doesNotUnderstand: (or create methods whose only purpose is to</FONT>
<BR><FONT SIZE=2>delegate)...what would really make it powerful is the ability to define</FONT>
<BR><FONT SIZE=2>and plugin specialized message lookup algorithms. I wonder if you could</FONT>
<BR><FONT SIZE=2>desing the system such that the VM looks for a specialized lookup</FONT>
<BR><FONT SIZE=2>algorithm in the Class, if it doesn't find one, it uses the default, if</FONT>
<BR><FONT SIZE=2>it does find one (by finding a selector), it invokes that method to</FONT>
<BR><FONT SIZE=2>locate the selector. The custom "method lookup" method could optionally</FONT>
<BR><FONT SIZE=2>be implemented as a primitive for better performance. Anyway...I'm</FONT>
<BR><FONT SIZE=2>rambling now.</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 practice. I believe your usage was to coalesce the reference to a changable object, which would be polymorphic in protocol, to avoid the cost of a #become:. Is this right? If I were to use a delegation model, or a managed object model, then I think the forwardee is the delegator or manager. This still results in the same identity of self issue between the manager and the managee. I don't think DNU would work at the manager for this reason, given that they are serially composed. What if we make the manager and the forwardee siblings in the Forwarder. Then the normalSend primitive could activate the manager with the following:</FONT></P>
<P> <FONT SIZE=2>#preActivateMethodSelector: aSelector withForwarder: aForwarder </FONT>
<BR> <FONT SIZE=2>#postActivateMethodSelector: aSelector withForwarder: aForwarder</FONT>
<BR><FONT SIZE=2>Unfortunately, I think this requires a callback mechanism from the VM, because we really want the same context on the Smalltalk stack, right? Perhaps we instrument the byte codes, with a new activation prolog and postlog, so even a primitive method call would work.</FONT></P>
<P><FONT SIZE=2>How could we do this? As an example, I use the Trampoline to asynchronously send messages, and I manage them by generating a Future and registering handlers for the normalReturn/exceptionalReturn, before I send the message asynchronously. Another example would be a remote Delegator. </FONT></P>
<P><FONT SIZE=2>-Rob</FONT>
</P>
<P><FONT SIZE=2>- Stephen</FONT>
</P>
<BR>
<BR>
</BODY>
</HTML>