Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!bloom-beacon!eru!luth!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.object
Subject: "Messaging" (Was: Re: Reentrant code)
Message-ID: <1452@tukki.jyu.fi>
Date: 10 Oct 89 13:36:43 GMT
References: <11242@eerie.acsu.Buffalo.EDU> <4513@internal.Apple.COM> <24517@dcatla.UUCP> <4540@internal.Apple.COM> <996@skye.ed.ac.uk>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 68

In article <996@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <4540@internal.Apple.COM> Piersol@apple.com (Kurt Piersol) writes:
>>Now here's an interesting thought. Am I in fact incorrect in assuming that 
>>all OOP systems contain some concept of messaging?
>
>Well, in Lisp, the difference between
>
>   (send instance operation other-arg...)
>
>and
>
>   (operation instance other-arg...)
>
>doesn't look all that great to me, and I think a similar equivalence
>might be drawn in other languages.  Besides, do we really want to
>argue that C++ isn't object-oriented just because calling a member
>function doesn't involve a syntax that looks like sending a message?

Our site has missed approximately a week's worth of news articles
(in all groups), so I have seen only the last one in this chain.
Let's hope I am not repeating something that has just been said.

It has been explained now and then in the literature that the "messaging"
terminology as used by the Smalltalk-80 (TM) community is misleading.
For instance, although Brad J. Cox conforms mostly to that terminology in
"Object-Oriented Programming : An Evolutionary Approach" (Addison-Wesley
1986, 1987), he notes (on p. 50 in the 1987 printing):
 "Every programmer knows that calling a function blocks the caller until
  the called function finishes. But message sounds like something more is
  going on. Newcomers struggle, searching for the implied promise of a
  concurrency mechanism and miss the real contribution."

In some languages (e.g. Eiffel (TM)), every procedure (operation, routine)
belongs to some object, but their literature just does not speak of
"message passing".
In Simula (TM), C++, and several other languages, invoking an object operation
can be distinguished from an ordinary function/procedure invocation at compile
time, in most cases even by syntax. Also, they do not force late (run-time)
binding of all object operations.
In the Lisp style given above, there is no statically detectable difference
between ordinary function invocations and object operations. However,
it seems that this situation has been turned into an advantage in the
"multi-methods" of CLOS, where several objects participating in an operation
can be in a more symmetric position.

The main reason why practically none of the languages created by extending
more conventional procedural languages can be regarded as purely
object oriented is that one can program in them even without using
objects or classes. Further, if the base language happens to be C,
it is hardly possible to protect the _integrity_ of objects from
C-level tricks and errors. Still more specifically, in C++ there is no
strong _identity_ concept; in this respect it is less OO than e.g.
Objective-C (TM).

Please note that you can find in the literature parallel/concurrent OOPL's
where "message passing" really means message passing: objects have
queues for incoming messages, and so on. The most classic example
are probably the Actor languages of Hewitt and others - to add
confusion, there is currently on the market a language trademarked
Actor, which has no connexion with these principles, but is rather
Smalltalk-like.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland