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: 31 Dec 91 11:00:15 GMT From: netcomsv!objsys@decwrl.dec.com (Bob Hathaway) Subject: Re: Multiple Inheritance in Ada 9X Message-ID: <1991Dec31.110015.17844objsys@netcom.COM> List-Id: [This turned out fairly long. I think any CLOS responses should be directed to comp.object and perhaps comp.lang.clos] In article barmar@think.com (Barry Margolin ) writes: --Oh boy, a posting from an object system. I guess OO technology has come --pretty far! Actually, I forgot to fill in my name above (it defaults), so I feel its important to point out that this programs opinions are its own and not necessarily the opinion of its writer. -->>accessible. And CLOS's MI semantic definitions are a real mess. --Other than the precise details of the order of classes in the class --precedence list, what's a real mess in CLOS? Since the precise order of --the CPL is generally unimportant (i.e. most programmers are only concerned --that the total order be consistent with the local order of a class and its --direct superclasses), this shouldn't be much of a problem. Well, thanks for answering. I haven't grabbed a PD CLOS compiler yet, so I had to go by the articles instead of writing test programs, giving their definitions a try. "The Common Lisp OO Programming Language Standard", 4.3.1 Inheritance Conflicts starts by stating each superclass is listed once in its class precedence list(hmmm). It then describes how CLOS prioritizes the parents in order from left to right (interesting, what if I don't want to define an ordering? Can I access the lower priority class slots at all? Can I query the class if necessary and then specify the path?). And then there's point three: When direct superclasses are independent except for a common ancestor class, a similar property holds [left to right priority of parents], provided that the common ancestor appears only as the last element of a direct superclass list., never in the middle of one [???]. The class precedence list consists of the noncommon superclasses of the first direct superclass, followed by the noncommon superclasses of the second direct superclass, and finally the common ancestor and its superclasses [???]. I figured out the first ??? a while ago, but maybe a real CLOS programmer can give a good example. 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...). And further, does this mean all common superclasses are shared? If so, this seems like dangerous, large granularity (class-level) structural sharing to me. I can define two independent classes each inheriting from say, a list class. Each of these two classes depends on its own list parent. With shared superclasses, if I define a new class which inherits from both, both parents integrity is compromised! It looks to me that if I use MI in CLOS, I must check for such duplications and may be precluded from combining certain classes as parents (obviously not so when shared and non-shared superclasses are available, as in C++). Do I understand the CLOS definitions correctly? Can I get non-shared superclasses in CLOS? --> Since -->a scope resolution path seems to solve C++'s problem, it could have just -->been C++ nitpicking and confusing semantic rules in CLOS (i.e. a general -->lack of understanding *and* early implementations). --What "could have just been ..."? The individuals complaining that single inheritance is preferred to multiple inheritance, I think they lacked understanding *and* only saw incipient work (I was also joking to make a point). There is also the Object Specialization camp, which provides the equivalent of MI thru object hierarchies but I still prefer MI since it is far more convenient than constructing object hierarchies linearly and because MI fits in with hybrid prototype/class OO systems well. I feel these authors fell into the "very early" category and should consider removing their tree hierarchy constraint because of simplicity of use. Any other opinions? 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? [Covering method combinations] I agree, method combinations are a nice facility. I assumed Dr. Stroustrup was referring to CLOS's dynamic nature, which I think can coexist with a static nature just fine (what I'm doing). Can CLOS take advantage of static facilities? If not, can meta-level access provide this for efficiency and compile-time checking? How about CLOS and prototyping, is it provided or can meta-level access help? -- The main --thing I think matters the most is that "mixin" classes can be --established in a library, and then users of the library can draw upon --them and use them together in whatever pattern in appropriate. This --is harder or impossible to do in C++ and most non-CLOS-like approaches --that I am aware of. Could you please explain how mixins differ from ordinary classes? They look like ordinary classes to me; are you referring to method combinations? 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? 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? Has the lack of encapsulation/protection gotten in the way of reliable, large-scale systems building? Inquiring minds want to know... --This is exactly what I mean about language theorists. In fact, it's --not a "semantic mess". It's well defined, and in real-life --circumstances it's simple and natural. Many programmers who I worked --with, including me, used this stuff (actually its predecessor, --Flavors; CLOS is actually an improvement) every day, for years, --producing many, many thousands of lines of code, with no problem. Well, I admit I haven't used the language yet, but I'm genuinely interested in the answers to the previous questions. I was speaking from a software engineering perspective, not a theoretical one. -- Maybe you're the kind of person who never uses a hammer --under any circumstances because it is possible for the hammer head to --fly off and cause damage, and so you're waiting for the Perfect --Hammer. But there are plenty of CLOS programmers who find it to --be a very useful tool, and they'll happily use it until a better --one comes along. That is my intention (providing a better one that is:-) bob objsys@netcom.com