Re: MI - clutching at straws

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj@ucbvax.Berk eley.EDU (John Goodsen)]

eachus@Dr_No.mitre.org (Robert I. Eachus) writes:

>
>   >>A program which has objects which are simultanously in lists and trees,
>   >>and uses MI to manage both structures is a mess.  Such a program can be
>   >>created and made to work, but the list primitives will have to be aware
>   >>of the tree primitives and vice-versa.
>
>   > It's not very persuading to point out a poor design and then state
>   > that the technology was the fault.
>
>   I think you are agreeing with me, but the quote out of context
>seems to say something I didn't intend...
>
>A design which contains objects which are simultaneously in lists
>and trees is not inherently a bad design.  


No, but your intent to insist that the 2 classes must be "aware"
of each other is what I refer to.  Your arbitrary choice of a poor
design example for MI does not invalidate the usefulness of MI.

>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.
>

There is no need to confuse the *insertion* of an object into
multiple containers with multiple inheritance.  To argue this silly
example is moot.  You need to come up with a valid MI example before
you start knocking the usefulness of MI.  -- Bob Crispen -- where's that
MI summary post ?

>
>     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.

I no way have you shown the SI approach to be much cleaner. Misleading
statements like this are of no usefulness in the pursuit of the MI truth.
To insist that inheritance only exist within single threads is somewhat
fascist, IMHO.

Use a little Jeet Kun Do:  "Absorb what is useful, disregard what is not"

It is silly to say multiple inheritance is *never* useful.  Just as it is 
silly to say single inheritance is *always* cleaner.  Neither statement is
correct.  The correct answer is:  Use MI when it makes sense, use SI when
it makes sense.  The 2 concepts are not contradictory.  

>--
>
>                                        Robert I. Eachus
>
>with STANDARD_DISCLAIMER;

28~
John Goodsen
goodsenj@ajpo.sei.cmu.edu
-- 
John Goodsen                              Ada Joint Program Office
jgg@evb.com                               PCIS Programme
800-877-1815                              goodsenj@ajpo.sei.cmu.edu