From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: MI vs. SI
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 27 Jan 1993 16:39:34 GMT

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.

	The biggest problem in C++ have nothing to do with MI,
but to do with the type system. Next perhaps, templates and
exceptions. These are respectively the oldest and newest features
of the language.

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

	I dont have much trouble understanding it, and my compiler
seems to implement it faultlessly. Its main flaw is something
trivial: it cant determine whether a class is abstract or concrete
correctly. The fault is due to poor wording in the ARM.

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

	So can pointers.

>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

	Seems like a good idea to have one class for each fundamental
concept---even if you are not sure if the concepts will be used
independently.

	After all, combining two such classes to make a new
one is trivial with MI. Why burn your boats?

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

	If this is common use, then more education is needed on
how to use MI well. In fact, on how to use inheritance at all.

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

	Sure, but this is spurious: using SI in the LIST situation
is equally bad because in both cases you have to use downcasting.

>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 dont agree. Perhaps using MI properly requires a major
paradigm shift, in particular, away from the Smalltalk Object 
Heirarchy which is not suitable for C++.

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

	Yes, indeed, such a mechanism cannot be considered subclassing,
and is best handled with discriminated unions wherever possible.

>   The escape from such bad design is with MI,
>   and I don't like it. Sure, you can tell me not to use/buy/touch such 
>   code, but in the real world we have to compromise. Call us "Nazis", for
>   we would like to force you into "good design" by limiting your options.
>   This might hurt the super-smart designer, but improve the average programmer
>   productivity. And yes, we are concerned with the later. The former can
>   find a smart way to overcome the limits anyway, when required.

	I dont understand your argument: you first say the 'escape'
from bad design is to use MI, then say you dont like it?

	Why not just teach programmers how to use MI properly?

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

	NIH from the sound of it would be better of it is simple
didn't exist. I dont think such a monolithic monstrosity can be
fixed. Just dont use it.

>Show us an example! Many people in this group have been claiming for some time
>now, that they are yet to have seen code where MI is needed when the 
>classes are correctly designed (w/templates) from scratch. 

>The last example on the net was a bank account class, from which credit and
>debit accounts were derived, and then MI was used to combine their functions.
>This is a typical bad example. How are the accounts stored on the disk?
	
	Irrelevant: that question can be asked of any class.

	No I take it back: in fact MI provides an excellent
(user controlled) idiom to allow easy storage to disk.

>wouldn't the code as a whole be shorter and easier to understand if
>these where combined into one class? 

	No, its better to encapsulate the smallest possible
independent units without going completely overboard and deciding
that one function is the smallest functional unit :-)

>Only when real code is presented, to
>achieve a real task, can we truely compare such approaches.

	I'm working on a 'real' example. Please wait. So far
the idea is for a mini-database (no, not object oriented :-)
with device independent screen access and windows. 
It does take a few lines of code to make such a thing work.

>
>No doubt someone will tear this posting apart. Each point will be attacked
>independently. 

	:-)

>I am sure I will be flamed for my own stupidity for not 
>understanding the simple concepts behind MI, which are so obvious. 

	No. Almost no-one understands how to use MI properly.
You will not be flamed. Your position is supported by prominent
academics.

>You will
>also tell us that soon, soon, MI will be implemented perfectly, and that you
>have already used it in 100k lines project and it was indispensable.

	Yes. I've done a project where MI was mandatory.
(Because the linkage was dynamic: absolutely no possibility
of downcasting.)

>Never the less, many people will remain steadfast in their believes in
>many of the above claims. We don't believe this complexity is necessary,
>and we would like a shorter reference manual!

	So just dont use MI. You dont have to.

>
>Of course, we lost the battle a long time ago. 

	Yes.

>Lets design ++C.
>
> Michael Golan
> mg@cs.princeton.edu

	Interestingly, I read ++C as 'incremental C'. 
And you can get this with mixins and no other way
(short of delegation=dynamic inheritance)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
Xref: sparky comp.lang.c++:19704 comp.lang.smalltalk:2783