lpd@aladdin.com (L. Peter Deutsch) (03/06/91)
Since I gave a talk last week precisely on this subject, I feel more confidently opinionated about it than usual. :-) In my opinion, there are two historical threads that have led to today's OO languages. One of them is dynamic overloading of named closures. This is the one that PCG has been discussing; it naturally leads to multi-methods (e.g., CLOS), and symmetric consideration of the name and the arguments for dispatching (e.g., Ossher's "grids"). The other is the Actors view of communicating protected processes. This has led to the work on modeling various forms of OO system organization in concurrent logic programming languages, for example. I happen to think that both of these views are valid and interesting. The former has been the dominant one, but I believe the latter has more profound implications at the *system* level, which is where most of the non-language work in OO technology is going on, and which is where I feel OO technology has a unique contribution to make. Conceptually, the two views are somewhat at odds, since the former seems to require a dispatcher that has access to a complete set of implementations of an operation, while the latter requires only that an object know about the operations it implements. Of course most of the distinction can disappear at the implementation level for non-distributed implementations, but it reappears when one moves to the system level. I had an interesting discussion with Danny Bobrow about multi-methods at the symposium where I gave the aforementioned talk (and where he gave a talk about CLOS). I don't much like multi-methods, because I feel they destroy the simplicity of the class as the single unit of *design*. What we concluded after some conversation was that if one is going to have multi-methods, it is essential to have some new tools and concepts (such as the concept of a module, perhaps) for organizing one's program, in addition to the use of the class / type structure. I've never seen this admitted in print by people who advocate multi-methods; it would go quite a way towards overcoming my principal objection to them, especially if I liked whatever was being proposed in the way of new structures.
pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) (03/08/91)
On 5 Mar 91 16:35:15 GMT, lpd@aladdin.com (L. Peter Deutsch) said: lpd> In my opinion, there are two historical threads that have led to lpd> today's OO languages. One of them is dynamic overloading of named lpd> closures. This is the one that PCG has been discussing; it naturally lpd> leads to multi-methods (e.g., CLOS), and symmetric consideration of lpd> the name and the arguments for dispatching (e.g., Ossher's "grids"). Yes, yes. This is the traditional Simula 67/Smalltalk view of the world. (I seem to remember that it was Fabry that first introduced the notion of an interface/type -> implementation matrix, in his seminal article on capability systems). lpd> The other is the Actors view of communicating protected processes. This I did mention too, and is the Plasma (I seem to remember that this was the name Hewitt gave to his language) view of the world. lpd> I happen to think that both of these views are valid and interesting. Ah yes! One problem I see though is that actually Smalltalk is not an Actor language, but a lot of Smalltalk terminology resembles Actor terminology, and this easily leads many into confusing the two. lpd> The former has been the dominant one, but I believe the latter has lpd> more profound implications at the *system* level, Uhmmm. I feel that actors somehow miss out on the distinction between instance and template. Frame based people say this is an artificial distinction, I am not so sure. Hewitt characterizes actors more or less by patterns of *behaviour*, not of structure, so there is little interest in structure templates. Thorny issues. lpd> which is where most of the non-language work in OO technology is lpd> going on, Capabilities! The system side of OO technology. lpd> and which is where I feel OO technology has a unique contribution lpd> to make. I am not so sure it has yet to happen. OO technology has already given a lot, under the name of capability technology, in this field. In other words, it has already happened :-). Even in the distributed case. My current main research is a sw capability based system that implements not distributed actors, but distributed type managers. On the other hand, and I will let another cat out of the bag, I have believed for the past dozen years that there are two fundamentally and *radically* different ways of doing distributed programming, and that one is indeed process/actor, and not procedure/closure based. The problem is that not a lot of people seem to realize that the semantics involved are completely different, and *only* in the distributed case (for example in view of the world one way is characterized by non termination because of the possibility of deadlock but the impossibility of races, the other by the impossibility of deadlock but the possibility of races). But this is completely orthogonal to a discussion of OO technology. lpd> I don't much like multi-methods, because I feel they destroy the lpd> simplicity of the class as the single unit of *design*. This was my impression too once. But actually I have come to regard this as an advantage. The real point is the decomposition paradigm; clustering implementations only along *one* type dimension can generate poor decomposition boundaries in many interesting situations. In the rest (maybe a majority) of situations a language that enforces decomposition only along one type dimension maybe helps, but IMNHO it does make things too difficult in the other case. In other words, it is a linguistic feature that may unduly warp the choice of decomposition boundaries in one direction only. lpd> What we concluded after some conversation was that if one is going lpd> to have multi-methods, it is essential to have some new tools and lpd> concepts (such as the concept of a module, perhaps) for organizing lpd> one's program, in addition to the use of the class / type lpd> structure. Haaaa, definitely yes, of course. What you are saying here is that if one admits that decomposition clustering can be multidimensional one had better have this *evident* in the notation, at some level. This is like having single entry-exit control structures as language primitives instead of describing them with gotos. I agree! lpd> I've never seen this admitted in print by people who advocate lpd> multi-methods; Do I have to sign this article in blood while standing in a pentacle to make you happy? :-) I am not a well known advocate of multiple dynamic overloading, and news is not in print, but maybe you will be happy nonetheless. lpd> it would go quite a way towards overcoming my principal objection lpd> to them, Caution here: you cannot object to multimethods, only as to how they are made available. Multimethods are *necessary* in the general case, i.e. a fact of life, just like even more advanced things such as dynamic (re)definition of classes. For each of these technologies you have three choices, and only three: 1) restrict your programming only to those applications that don't require the technology. 2) simulate it in a language that does not support it with primitives, e.g. like dynamic overloading in C. 3) support it with language primitives, taking care that this does not unduly impact the applications that do not need it. lpd> especially if I liked whatever was being proposed in the way of new lpd> structures. Case 3) above is an interesting area of research :-). Finally: you should be very worried now. You seem to be on the same wavelength as myself... :-) -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk