Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.object Subject: Re: The essence of OO-ness Message-ID: Date: 7 Mar 91 17:00:30 GMT References: <83.UUL1.3#5127@aladdin.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 128 Nntp-Posting-Host: aberdb In-reply-to: lpd@aladdin.com's message of 5 Mar 91 16:35:15 GMT 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