From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 2 Jan 92 21:31:52 GMT From: odi!dlw@uunet.uu.net (Dan Weinreb) Subject: Re: Multiple Inheritance in Ada 9X Message-ID: <1992Jan2.213152.10322@odi.com> List-Id: In article <1991Dec31.110015.17844objsys@netcom.COM> "Bob Hathaway" writes: For ??? #2, this looks counter-intuitive. Moving common superclasses to the end of the list? I think this is confusing, since the scheme is not consistent (the search would go left to right, except...). I think Barry explained this already. The intuition behind this is "if class A is built on B, then A should come before B" since that's the way it works for A itself. There are controversies about the algorithm for ordering the CPL, but this isn't one of them; it's clearly right, once you grasp what the CPL is for. And further, does this mean all common superclasses are shared? Yes; as Barry said, in C++ jargon, CLOS does not support non-virtual inheritance. This is one place where C++ is more powerful than CLOS. In article <1991Dec30.201051.23038@odi.com> dlw@odi.com writes: >//As noted by Dan Weinreb, C++'s notion of MI is less powerful that that of >//CLOS. That was understood at the time and accepted as something that was >//probably a necessesary price to pay for C++'s static type checking and >//run-time efficiency. > >I must have missed this one, could you please give a pointer or summarize >why CLOS's MI is more powerful? Let me take this opportunity to add that "being more powerful" is not synonymous with "better, in every way". Often power comes with minuses as well as plusses; at the very least, it usually adds some complexity. I happen to have found method combination very useful at times, but I won't deny that one advantage of C++ that makes up for the lack of method combination is that C++ is simpler. Could you please explain how mixins differ from ordinary classes? They look like ordinary classes to me; are you referring to method combinations? Mixins are indeed ordinary classes, but they are called "mixins" when you intend to use them in certain ways. A mixin is a class whose author intended that the class get mixed into other classes in order to add some functionality. I can write a mixin M, and the you can write class A and simply mix in M, and your friend can write class B and mix in M. M does not "know about" A or B in any way. And the important thing is that M can tack on additional behavior automatically because of automatic method combination. So the concept of "mixin" is really only an interesting concept because method combination exists. Also, while I've got a real CLOS programmer here, I've wondered about multi-methods and no class structuring. Does this get in the way? Actually, I've never programmed with multi-methods. My own experience is with one of the predecessors of CLOS (namely, Flavors) that didn't support multi-methods. So I can't answser from experience. Since dynamic functions or dummy receivers superset multi-methods but I don't think multi-methods superset OO-style invocations, have you ever worried some operation on a class would get pulled away by some other multi-method which matched closer on some later parameter? That's a good question and I don't know to what extent this really happens. I do know that with static overload resolution, which is sort of analogous to this, it is indeed possible to get confused when things get complicated. Has the lack of encapsulation/protection gotten in the way of reliable, large-scale systems building? Inquiring minds want to know... Ah, well, that's a bigger question. I do think that Lisp would be better off with a better encapsulation/protection paradigm. What it has right now is "packages". I am one of the people who invented this, and I am not happy with it. If I were going to do a major overhaul, this is one of the main things I'd want to work on. You might want to see whether the Scheme developers have come up with something good in this area; they're really the vanguard of Lisp development as far as I know.