Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!mcnc!unc!rentsch
From: rentsch@unc.UUCP
Newsgroups: comp.lang.misc
Subject: Re: More on OOP
Message-ID: <743@unc.unc.UUCP>
Date: Fri, 30-Jan-87 01:28:41 EST
Article-I.D.: unc.743
Posted: Fri Jan 30 01:28:41 1987
Date-Received: Sat, 31-Jan-87 09:28:20 EST
References: <8049@tekecs.TEK.COM> <793@watmum.UUCP>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 43

In article <793@watmum.UUCP> gvcormack@watmum.UUCP (Gordon V. Cormack) writes:
> In article <8049@tekecs.TEK.COM>, jeffmc@tekecs.UUCP writes:
> > From the users point of view, asking something to do something by
> > using a message is very different from invoking a function.  Just
> > think about who is in control.  

> Exactly.  No matter how you dress it up, the *caller* is in control.
> Now, if the object were operating as an independent process with
> a thread of control, it would be appropriate to call it a message.
> And message-passing process-oriented programming is a useful 
> paradigm ....
> It is apparent that messages in Smalltalk are really procedure
> calls when you have a look at its brain-damaged support for 
> concurrency.

I must admit, the word "message" is a bad choice because of the
confusion with the process-related definition.  I stress message
SENDING in OOP to contrast with message PASSING for multiple process
stuff.  (To be fair to the OOP people, they were talking about
sending messages long before the "message sending" terminology was
common usage.  It just goes to show you, there aren't enough words
for computer science. :-)  

If you think of message *sending* and compare it to message
*passing*, then indeed sending looks more like a procedure call than
the asychronous data transmission of message passing.

Such a comparison, however, distinguishes along an axis which is
(largely) irrelevant to OOP.  When asking "who is in control", this
question is meant not in terms of "who has the PC", but rather in
terms of "who dictates how the message is to be interpreted, and who
decides what is to be done in response".  In that light, the message
receiver (or callee, if you prefer) is in control -- when sending a
message, you do not know (in principle, *cannot* know in general)
what method (procedure, if you prefer) will be activated to respond
to your message.  If, when programming, the programmer takes the
point of view that not only can he NOT know what the method will do,
but that he doesn't WANT to know, then I would say that he is
practicing OOP.  

cheers,

txr