Forwarder

Stephen Pair spair at advantive.com
Wed Jul 25 22:07:00 UTC 2001


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

Thanks!  No, I didn't do the trampoline...someone else did (can't
remember)...but, I incorporated into a little asynchronous messaging
demo that I did.

>[rob - delegation hooks] 
>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?   

Yes, roughly...I wouldn't think of it as coalescing...there are still
two distinct objects, one just delgates everything it receives to the
other.

>If I were to use a delegation model, or a managed object
>model, then I think the forwardee is the delegator or manager.  

Actually, this is the opposite of the way I would describe it.  I would
describe the Forwarder as the delegator, and the forwardee as the
delegatee (is that a word?)...I don't really remember what (if any)
standard terminology has been established regarding delegation.

> 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:
>        #preActivateMethodSelector: aSelector withForwarder: aForwarder

>        #postActivateMethodSelector: aSelector withForwarder:
aForwarder 
>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.

I think you've lost me...also the Forwarder would not be used at all in
delegation (it can't because because no method will ever be activated
for any of its instances)...in my mind delegation requires that you be
able to send a message to an object, and receive any messages that are
sent to self in the target method.  It's kind of like dynamically
subclassing the target object, but it only affects the instances
involved, it is only in effect for the duration of the delegated message
send, and the two objects remain distinct (having separate
state...unlike subclassing, in which instances reflect a union of all
instance variable in the class and its superclasses).

DNU comes into play when a delegated method context sends a message to
self, which would get routed back to the delegator...which may not
natively understand the message and desires to once again delegate (this
is analogous to the the lookup of a method in the superclass chain).
Alternatively, the delegator may implement the method, and choose to
delegate it, optionally adding behavior of its own (this is analogous to
a super send).

Of course, you would need to support additional syntax to generate a
"delegated send" bytecode. 

So, having a mechanism to define a custom lookup could be beneficial.
You could choose to first do a normal lookup, then try one of several
instance variables for potential delegation, or any number of
possibilites.  I don't think calling back into Smalltalk for that would
be an issue...the default case of a normal lookup has to be handled
efficiently though.  And, you have to be careful not to melt down into a
infinte recursion trying to lookup the method lookup method lookup
method lookup method lookup method lookup....you get the idea.  But, I
think if you want the real deal...you have to go all the way to Self.

I haven't experimented with the delegation aspect...so, there may be
something in there that blows apart my whole notion of how it might
work.  I'm going to play around with the forwarding capability for a
while first.

- Stephen
 






More information about the Squeak-dev mailing list