From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: MI vs. SI
Date: 25 Jan 93 20:06:48 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.31 $

In article <mg.727630597@elan.princeton.edu> mg@elan (Michael Golan) writes:
> pandrews@lovat.fmrco.com (Paul Andrews) writes:
> >Totally agree. Why oh why oh why (:-)) do folks have such a downer on MI? 
> 
> Because
> 1) Most implementations are buggy. Maybe all those compiler writers are
>    idiots. Maybe the idea too complex and not well understood/documented.

Fair point. Most implementations ARE buggy. Likewise implementations of 
templates. This should soon pass.

> 2) MI is hard to implement, hard to understand, hard to use correctly

Presumably the buggy compilers indicate it is hard to implement. I find it
easy to use, and I think I understand it.

> 3) MI can add bugs that are hard to detect

Have you any evidence for this ?

> 4) MI lead to bad design, where people make one class into 3 (inhereting
>    from two smaller classes), just so that (1) and (2) could possibly be used
>    independently, even when this is not likely or important

I don't think this is an important criticism - almost anything can lead to
bad design if you look at it like this. Why anyone would bother to 
separate out functionality that is never going to be reused ?

> 5) MI is commonly used as a hack to combine incompatible classes that 
>    are badly designed to begin with. This might be nice and good in the 
>    short-run, for older C++ classes designs. It is most likely bad in the 
>    long run.

MI can be used for this, yes. When the classes are from a library vendor, 
and cannot be changed, this is a legitimate use.

> 6) They were mostly needed before the templates-era, when classes where used
>    in implementing template-concepts, e.g. when a class had to be derived
>    from LIST to be on the list. Then, when you wanted to collect some
>    functionality on a list, you had to use MI. You still have to do so,
>    if your "LIST" is some complex class, that *combines* a collection-
>    mechanism with other functionality. Most such designs are bad, and 
>    using MI instead of fixing the design is a bad idea.

Maybe that's why YOU used them. Not I.

> 7) The complications to the language far out-weight the benefits, and it
>    seems to have no end in sight. See dynamic_cast<Ouch>(Arr)

I disagree.

> 8) People abuse SI. I have seen many abstract classes with a field "type",
>    which is set by each derived class and is checked at both levels.
>    I consider this "cheating". 

So do I.

>    The escape from such bad design is with MI,
>    and I don't like it. 

Is it ? How ?

> You claim that the NIH lib would be better off with MI, and that this is
> "clear". I challenge you to a battle of wits (The princess's bride:-).
> Show us an example! 

Have you looked at my posting <727040791snx@trmphrst.demon.co.uk> in this 
group ? I gave an example of MI there, and asked for comments. Perhaps you
would care to redesign it using SI, and explain why the SI design is as 
good (or better) ?


-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++