Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jpd00964
From: jpd00964@uxa.cso.uiuc.edu
Newsgroups: comp.object
Subject: Re: "Sender" construct in OOLs
Message-ID: <132000001@uxa.cso.uiuc.edu>
Date: 12 Oct 89 15:28:00 GMT
References: <89@<TIME>
Lines: 42
Nf-ID: #R:<TIME:89:uxa.cso.uiuc.edu:132000001:000:2263
Nf-From: uxa.cso.uiuc.edu!jpd00964    Oct 12 10:28:00 1989


/* Written  5:09 pm  Oct 11, 1989 by alonzo@microsoft.UUCP in uxa.cso.uiuc.edu:comp.object */
In article <9450013@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>> >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 
>> >
>> >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.

The sender must still pass its address which means that it must allow someone
else to be able to access its instance variables at the called objects will.

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

That may be the theory, but not the practice in Obj-C on the NeXT.  A sender
is actually encouraged as that limits the amount of irrelevent information sent.
A sender is a very very powerful construct which I am sure must be able to 
be implemented with c++.  I do not know of any way offhand, but with a little
"syntactical sugar", I am sure someone will come up with a method.  Hopefully
he will not try to patent it though :->

Michael Rutman
Softmed
dpd00609@uxa.cso.uiuc.edu