Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!dogie.macc.wisc.edu!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.object
Subject: Re: "Sender" construct in OOLs
Message-ID: <9450013@hplsla.HP.COM>
Date: 9 Oct 89 19:09:25 GMT
References: <TIME.89Oct4131658@oxtrap.oxtrap.UUCP>
Organization: HP Lake Stevens, WA
Lines: 51

>dchapman@portia.Stanford.EDU (David Chapman) /  3:40 pm  Oct  8, 1989 /
>In article <9450008@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>>You should be able to do this using function call overloading in C++.
>>I suspect its not trivial to figure out, however.
>
>After thinking about this some more, I cannot conceive of a way to
>implement the "sender" construct.  Why?  Because the "sender" is of 
>arbitrary type.  *Anything* can send an object a message.  That's the 
>whole point.  Maybe Smalltalk or Flavors could handle this by looking 
>up the type of the object, but it would be horrendous to do in a 
>compiled language like C++.
>
>Comments?  Remember, the original poster wanted mutual recursion - he
>wanted to send messages back to the caller.

What I was thinking of is that a sender class overloads its function call
operator to push the sender "this" onto a stack as a prolog, 
and pop that "this" as a postlog in the sender function call operator 
overloading.  If no sender class method had been called, then the stack
of "sender this's" would be empty.  IE "a null sender."

Likewise the receiver class function call operator could be overloaded
to get a copy of the sender "this" from that stack and interpret it as
"sender", adding sender as a parameter to the underlying function call.

I suspect this approach would be painful to actually do in C++, since
each distinct set of function parameters requires a seperate overloading
of the function call operator, and since the receiver functions must
themselves be defined as objects of some class, so that operator(something)
can be applied to them.

Still, an object of a class not obeying the sender protocol could send a message
to a receiver, thus the receiver would find an incorrect sender on the stack.
But such a protocol-ignoring object would do its dirty work either within 
a sender method, in which case it could be considered a delegate of the sender,
or outside all sender methods, in which case the stack would be empty, and the
receiver would note that "no" sender sent the message.

An alternate approach is for both sender and receiver to implement these
protocols by overloading operator->, and require that any messages sent
to either sender or receiver be via "->" as opposed to "."  Operator->()
seems easier to use as opposed to operator(this, that, ortheotherthing) since
there aren't parameters to operator->().  On the other hand, operator->()
never regains control after method dispatch, so sender functions would have
to explicetely unstack their "this" [which is the receiver's "sender"]
before exiting.

For mutual recursion, either sender and receiver can be written as the
same class, or you can use multiple inheritence to "glue" together both
a send/receive capability in a mutual subclass -- assuming sender and
receiver are written orthogonally.