Re: MI - clutching at straws

[spool.mu.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.D E!grieg!pk@uunet.uu.net (Peter Klein)]

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