jeffmc@tekecs.UUCP (01/23/87)
Some comments: I consider dynamic (or at least late) binding as an important part of the power of OOP. The success of reuseable code appears to be contingent on dynamic binding. See Brad Cox's book for a lucid description. Our experience with OOP is that reuseable code is possible and, in fact, probable. Software factories are possible and if we don't do them then someone else will. Class hierarchies and message passing (the OOP word for polymorphism) give this power. A serious problem in S/W for the the real world (people who have problems that need solving and who are concerned with the useability of the solution) is that S/W is not useful. It may be fast but it is not what is needed. OOP appears to put the necessary power in the hands of the developer to develop what is needed from the customer point of view. We find folks doing very rapid prototyping using OOP and being able to quickly try out ideas from designers and customers. When designs are 'complete' the implementor can worry about specific performance issues. The rate that hardware performance is increasing is making performance a non-issue for more and more problems. This is especially true in the area of human computer interface - humans don't move that quickly. HCI is also very hard to specify without prototyping. I am not avocating this approach for all problems but it is very useful for many problems. Another serious problem is the question of integration and maintenance. All of the multiple person OOP projects we have worked on or worked on with customers have had extremely easy integration. Encapsulation does it. Maintenance also has proven to be easier since the modification of one portion of code rarely changes behavior in unexpected ways. The OOP approach usually makes it very easy to find the location of errors. I have taken medium sized Smalltalk code that I have never seen before and then found and fixed bugs in minutes (I mean that - not hours!). One last comment: There has been discussion here and in other places about the 'silliness' of using a message passing syntax. Closure works, or just use functions, or some such. I disagree strongly. B.L Worff has hypothesized that the language you use directly affects your thought process. We have found that even within a OOP program the actual names (selectors) used for the messages can have a strong influence on the understanding of a piece of code. 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. The two methods may in fact be isomorphic but only in theory, not in practice. What I really want is the ability to invoke a function when that is the obvious thing to do and send messages when that is the obvious thing. But I don't want to do this by cobbling up some strange syntax. Thanks, Jeff McKenna (503) 685-2943 jeffmc.tekecs@tektronix.com
gvcormack@watmum.UUCP (01/24/87)
In article <8049@tekecs.TEK.COM>, jeffmc@tekecs.UUCP writes: > I consider dynamic (or at least late) binding as an important part of the > power of OOP. > ... a well written argument (that I disagree with) that dynamic binding is essential to software reusibility ... > One last comment: There has been discussion here and in other places > about the 'silliness' of using a message passing syntax. > ... We have found that even within a OOP program the actual > names (selectors) used for the messages can have a strong influence on > the understanding of a piece of code. No argument. Why is this restricted to OOP? > 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 (but could still benefit from strong typing). Read Gentleman's paper in SP&E (1980 - don't have a more precise reference). It is apparent that messages in Smalltalk are really procedure calls when you have a look at its brain-damaged support for concurrency. -- Gordon V. Cormack CS Dept, University of Waterloo, Canada N2L 3G1 gvcormack@mum.waterloo { .CSNET or .CDN } gvcormack@water { UUCP or BITNET }
rentsch@unc.UUCP (01/30/87)
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