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: 9 Sep 92 14:24:34 GMT From: spool.mu.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.D E!grieg!pk@uunet.uu.net (Peter Klein) Subject: Re: MI - clutching at straws Message-ID: <1992Sep9.142434.3940@Urmel.Informatik.RWTH-Aachen.DE> List-Id: In article 92Sep8135021@Dr_No.mitre.org, eachus@Dr_No.mitre.org (Robert I. Each us) writes: > A design which contains objects which are simultaneously in lists >and trees is not inherently a bad design. But if you need to do it, >the programmer needs either to develop a set of higher level >abstractions or pay attention to details when an object is say removed >from a list. (If the object is also an interior node in the tree, do >you have to delete it from the tree first, or just remember its >children and reinsert them? Is it legal to have objects that are in a >list but not in a tree, or vice-versa? And so on.) It can be done, >BUT if list and tree primitives are separately inherited the >programmer has to do most of the work. A much better approach would >be to use single inheritance from a tree type, and extend it with list >primitives which are sensitive to the tree structure. The progammer >must still answer the same questions, but only in one place--the >definition of the list type. > > So what I was really trying to say was that in this example it is >dificult to compare relative advantages and disadvantages of different >MI approaches, since any SI approach is so much cleaner. Well, I agree with you in the list/tree example. But, if you remember my first post, I already excluded such cases where MI is used to combine independent classes. This is not only dangerous, it is also a design which can be easily implemented without MI (and without inheritance at all). Unfortunately, your arguments don't hold in my example, where several extensions of the same base type are combined. The resulting type is essentially the base type augmented by an arbitrary subset of the possible extensions. The problems you mentioned cannot arise in this context. Furthermore, it is pretty awkward to simulate such behaviour without MI. In your previous post, you wrote: >In article <1992Aug31.153641.29954@Urmel.Informatik.RWTH-Aachen.DE> >pk@rwthi3 .informatik.rwth-aachen.de (Peter Klein) writes: > > In a more general sense, it cannot be reasonable to extend a basic type > by inheritance or by genericity depending on the fact whether you want > to combine some extensions later on. If you think that the extensions > should be done by inheritance, you'll end up missing MI if you want to > combine extensions on a higher level. On the other hand, if you say that > the extensions should be done using genericity, you won't need MI. But > in this case, you don't need inheritance at all. > > Close. IMHO inheritance is one of the least important OO features >being added to Ada 9X, but as I mentioned above it does have its uses. >In Ada 9X as in Ada 83, generics will be a much more powerful tool, >and should be the tool of choice in many areas where inheritance is >naturally used in other OO languages. Not true. Inheritance is the more powerful feature. Dynamical binding cannot be done with genericity; you'll never get true polymorphism without inheritance. But I don't think this is the question. Genericity and inheritance both have their uses, and most of the time the design makes clear which of them is appropriate in a given situation. If you think that inheritance is not *really* needed, I can accept that. But my original question was: What do I loose when I have SI only? In what way does the lack of MI affect the usefulness of the whole inheritance idea? *If* I think extensions of a base type should be done using inheritance, how do I solve the problem of combining independent extensions afterwards? Peter --- Peter Klein E-Mail: pk@rwthi3.informatik.rwth-aachen.de Lehrstuhl fuer Informatik III Tel.: +49/241/80-21320 Ahornstrasse 55 Fax.: +49/241/80-21329 RWTH Aachen D-5100 Aachen Germany