djones@megatest.UUCP (Dave Jones) (10/07/89)
From article <4540@internal.Apple.COM>, by Piersol@apple.com (Kurt Piersol): > In article <24517@dcatla.UUCP> itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) > writes: >> (Messages are specific to certain implementations of OOPS) > > Now here's an interesting thought. Am I in fact incorrect in assuming that > all OOP systems contain some concept of messaging? Yep, you are are incorrect in assuming that. > I have difficulty > imagining why one would bother with OOP at all without an idea of > messages, I have difficulty imagining why you have difficulty imagining that. Perhaps something is going around. An imagination virus maybe. There are plenty of reasons to orient programs around objects, without looking up procedures in hash-tables. Try using both standard C and C++ for comparison. C++ has several features which makes it easier to use than plain old C. That's why it exists. But it does bot have "messages". > ... I can recall a few systems claiming to support OOP which > had no message concept, but instead claimed operator overloading amounted > to the same capability. Who said that? It is obviously not the same capability. Each has its own advantages and disadvantages. And of course there are still other ways to bind functions. Storing pointers to functions within structures, (so-called "virtual functions"), is another technique that has practical value. > I suppose I just dismissed that notion out of > hand. What say the rest of you? I find few applications for messaging which can not be handled in some more direct way. The only system I can recall building which used messaging in a fundamental way could not have been implemented directly using most message-based languages, because the messages were sent between processes on different machines. Come to think of it, it was really a substitute for static binding of interprocess function calls, a concept which I have never seen implemented. Perhaps if I routinely used a language with messaging built in, I would find more application for it, but I am dubious. If it were really that useful, I think I would have invented a home-grown method. It's not that hard to do in an ad hoc way. (The "Objective C" book has a clear description of one way to implement it.) I have some qualms about messaging. Concerns about type-security, etc.. What is the state of the art these days?
dchapman@portia.Stanford.EDU (David Chapman) (10/09/89)
In article <8636@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >I find few applications for messaging which can not be handled in >some more direct way. The only system I can recall building which >used messaging in a fundamental way could not have been implemented >directly using most message-based languages, because the messages were >sent between processes on different machines. Come to think of it, it >was really a substitute for static binding of interprocess function >calls, a concept which I have never seen implemented. Interprocess function calls imply blocking (you get a return value from the callee). Message passing implies no blocking (except perhaps for queue overflow). The return value is from the message passing system itself and tells you if the message was accepted (i.e. transmitted properly and acknowledged). This is a fundamental difference, and is an OS problem instead of an OOP problem (since most OOPs are not parallel programming languages). If your function calls don't block they are messages, by the way.
johnson@p.cs.uiuc.edu (10/10/89)
Of course C++ has messages! There is no essential difference between Smalltalk messages and C++ virtual functions. Although their implementation is entirely different, they are used the same way. However, not all o-o languages have messages. In particular, CLOS multimethods seem to be fairly different. Ralph Johnson
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/10/89)
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
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (10/10/89)
In article <5678@portia.Stanford.EDU> dchapman@Portia.Stanford.EDU (David Chapman) writes: > >Interprocess function calls imply blocking (you get a return value from >the callee). Message passing implies no blocking (except perhaps for >queue overflow). The return value is from the message passing system >itself and tells you if the message was accepted (i.e. transmitted >properly and acknowledged). This is a fundamental difference, and is an >OS problem instead of an OOP problem (since most OOPs are not parallel >programming languages). > >If your function calls don't block they are messages, by the way. Message passing is, in essentia, the passing of information (data) from one entity to another entity. The message passing paradigm can be blocking (wait for my call) or non-blocking (I'll drop you a letter). Interprocess communication is generally message passing since processes are by definition generally separate entities. A function call (irrespective of its blocking status) may or may not be a message, it depends on whether the concept of entities which can pass information is present in the program and whether the function actually passes information (in a blocking or non-blocking fashion). This does not demand the presence of more than one entity: an entity can send a message to itself but the concept of an entity must exist within the world view of the program. - -- "Geld groeit me niet op de rug." Literally: "Money doesn't grow on my back." (Often overheard at the supermarket counter from mothers to their kids.) Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
tombre@weissenburger.crin.fr (Karl Tombre) (10/11/89)
In article <135300001@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: >Of course C++ has messages! There is no essential difference >between Smalltalk messages and C++ virtual functions. Although >their implementation is entirely different, they are used the >same way. It is probably better to call this common use "dynamic binding". The "message sending" vocabulary became popular with Smalltalk. However, even Smalltalk messages are not that real !!! Think of it: a Smalltalk message is not an object. And communication remains synchronous: sending a message blocks the sender until it receives a response. You can find "real" messages in the actor model (Hewitt, Lieberman, Agha) or in some other languages, for instance Hybrid from the University of Geneva. The latter language has both synchronous and asynchronous communication, i.e. message can be sent in such a way that it blocks the sender, or it can be put into the mailbox of the receiver and liberate immediatly the sender. Once again, didn't we lose something from Simula, which had a "detach" instruction ? Karl Tombre - INRIA Lorraine / CRIN EMAIL : tombre@loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (10/16/89)
In article <135300001@p.cs.uiuc.edu>, johnson@p.cs.uiuc.edu writes: > There is no essential difference between Smalltalk messages and C++ > virtual functions. Well, not really. If you know (at run time) the name of a Smalltalk message (at compile time), you can arrange to send that message to an object. For example, I can say: obj perform: ( 'new' asSymbol ) More to the point, instead of using a String constant, I could have prompted the user for the name of a message to send. If the message doesn't exist, or takes the wrong number of arguments, you'll get a walkback and/or a debugger. That information is completely lost by run time in C++ programs. (On the other hand, C++ programs don't usually run in an environment where they can ask the user for help.) This is neither a general strength nor limitation of either language. The abilities reflect the intended use of the languages. > Ralph Johnson Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
johnson@p.cs.uiuc.edu (10/17/89)
I said >> There is no essential difference between Smalltalk messages and C++ >> virtual functions. psrc@pegasus.ATT.COM said >Well, not really. and mentioned perform:. I've used Smalltalk heavily for the last four years, and C++ off and on for the last three years. I still say that there is no practical difference between messages and virtual functions. One exotic application for perform: is in a distributed Smalltalk that we built, where a message to a proxy object on one machine would cause a string to be sent to another machine. The string was parsed and turned into a symbol, which was used to "perform:" the operation on the remote object. However, RPC systems do something similar using numbers instead of symbols, so there is no real loss of power. The big advantage of Smalltalk untyped messaging is that it is much better suited to experimental programming. Virtual functions are closely tied to C++'s type system, which forces the programmer to decide interfaces early. When the interfaces turn out to be wrong, as usually happens, the programmer has to make lots of revisions. However, from a high-level design point of view, I don't think that there is much difference between them. Ralph Johnson -- University of Illinois at Urbana-Champaign
jpd00964@uxa.cso.uiuc.edu (10/19/89)
/* Written 1:51 pm Oct 17, 1989 by jnh@ecemwl.ncsu.edu in uxa.cso.uiuc.edu:comp.object */ In article <135300010@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: >> >> >>I said >>>> There is no essential difference between Smalltalk messages and C++ >>>> virtual functions. >> >>psrc@pegasus.ATT.COM said >>>Well, not really. >>and mentioned perform:. >> >>I've used Smalltalk heavily for the last four years, and C++ off >>and on for the last three years. I still say that there is no >>practical difference between messages and virtual functions. One [much deleted] Doesn't Smalltalk/Obj C use run time binding and C++ use compile time binding? If this is the case, which I strongly believe it to be, then it should be very very easy to see that there is a big difference between them. If you have a look up table at run time, then you can literally put in any object you want, at run time, and the run time libraries will find you method. If you do it at compile time, then you cannot substitute in another object. QUICK CLARIFICATION---You can substitute objects, but it is limited in C++. At least it is in all versions I have seen, which is mostly Think C 4.0 on the Macintosh. Now, are you saying that you can do run time binding with C++? Michael Rutman Softmed
dog@cbnewsl.ATT.COM (edward.n.schiebel) (10/20/89)
From article <132000003@uxa.cso.uiuc.edu>, by jpd00964@uxa.cso.uiuc.edu: >[...] > Now, are you saying that you can do run time binding with C++? > Yes. that is what virtual functions are all about. Ed Schiebel AT&T Bell Labs dog@vilya.att.com 201-386-3416
jwd@cbnewsc.ATT.COM (joseph.w.davison) (10/27/89)
In article <135300010@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > > >I said >>> There is no essential difference between Smalltalk messages and C++ >>> virtual functions. > ... >The big advantage of Smalltalk untyped messaging is that it is much >better suited to experimental programming. Virtual functions are >closely tied to C++'s type system, which forces the programmer to >decide interfaces early. When the interfaces turn out to be wrong, >as usually happens, the programmer has to make lots of revisions. >However, from a high-level design point of view, I don't think that >there is much difference between them. > Basically, I agree, C++ virtual functions are pretty much the same as Smalltalk messages. However, one cannot escape the static typing/ dynamic typing distinction. The first time I came to see the big difference between C++ and Smalltalk was when I tried to implement ComplexNumber. In Smalltalk, when I operated on a ComplexNumber and the result had a 0 imaginary component, I returned only the real component, whatever type it was. That works nicely, to simplify many methods, and is similar to the way I use complex numbers. When I tried to write ComplexNumber::operator+(...) in C++, it became very clear what the difference was. Static typing not only forces early decisions about interfaces, it also precludes some approaches to problems. Some people think that's an asset; I tend to think some of the decisions it forces early are better made later. -- Joe Davison jwd@ihlts.att.com
itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) (10/29/89)
In article <2375@cbnewsl.ATT.COM> dog@cbnewsl.ATT.COM (edward.n.schiebel) writes >From article <132000003@uxa.cso.uiuc.edu>, by jpd00964@uxa.cso.uiuc.edu: >>[...] >> Now, are you saying that you can do run time binding with C++? >> >Yes. that is what virtual functions are all about. > > Ed Schiebel > AT&T Bell Labs To amplify; c++ allows the programmer to *control* binding points (compile time or runtime; per object function). So the programmer, rather than the language, can make the tradeoff decision between efficiency and abstraction. What a concept! :-) I understand that this is a "religious" issue; but I think it is nice that, for this particular language at least, the basic OOP concepts are supported while still retaining efficiency. Efficiency is not a dirty word. However, I'd happily admit that a "hybrid" implementation has serious limitations. I was in on the beginning of this thread, but missed the rest up until now. At the risk of redundancy: One of the nice things about the c++ imp of OOP is that, being "built on top of c", the objects are always passed on the stack. Thus, functions are inherently re-entrant, at least as far as the passed object instances go. I'm not saying c++ is better or worse than other languages, just that this is one interesting, and very important, side-effect of one particular implementation. I suggest that re-entrant capability is very important; and it would seem to be a shame if a language were to take away re-entrancy in order to add OOP. (But then; that's what this whole thread has been discussing, and I missed the middle part, so I'll shut up now). Bill Fulton