Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo Gariepy)
Newsgroups: comp.object
Subject: Re: "Sender" construct in OOLs
Message-ID: <8008@microsoft.UUCP>
Date: 11 Oct 89 22:09:23 GMT
References: <TIME.89Oct4131658@oxtrap.oxtrap.UUCP> <9450013@hplsla.HP.COM>
Reply-To: alonzo@microsoft.UUCP (Alonzo Gariepy)
Organization: Microsoft Corp., Redmond WA
Lines: 41

In article <9450013@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
> >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.

I think the problem here is an attempt to create general language support
for a non-general problem.  Many of the ideas expressed here do not
reflect the best modular design.  It is up to an object to define its
public interface; it is not good for the sender's address to be obtained
without its consent.  The provision of this address should be part of
an explicit protocol between sender and receiver.  In a type safe language
such as C++, this should be done by passing a typed pointer to the
receiver.

You are looking for some syntactical sugar to support a non-general and
questionable practice.  The basics of modular object-oriented design
favour classes that respond to messages and act upon their own state.
If an object is going to communicate with an instance of some other
class, that knowledge should be part of its state, not just some transitory
relationship to a particular sender that exists during the invocation of
some method.

Remote Procedure Calls and various other kinds of delegation and proxy
(such as iterator objects that send some message to all the members of
some collection on your behalf) should not have to cope with this concept
of sender.  I understand the utility of the features being discussed, but
they do not merit general support.

Alonzo Gariepy				// my opinions, not necessarily
alonzo@microsoft			// those of Microsoft