NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/20020

Text File | 1993-01-28 | 7.0 KB | 176 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!gatech!darwin.sura.net!sgiblab!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: MI vs. SI
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 1993 16:39:34 GMT
Lines: 163

In article <[e-mail]> mg@elan (Michael Golan) writes:
>[e-mail] (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
> [e-mail]

    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,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------