advice on programming style: is multiple inheritance bad?

[John Roth]

"Gary Stephenson" <garys at ihug.com.au> wrote in message
news:bvl0m8$tb3$1 at lust.ihug.co.nz...
>
> Fwiw, I am both a human, and a customer of my bank.  My computer is both
an
> "electrical_device" and a "depreciable-asset".  It is completely natural
in
> the real world for objects to have multiple "is-a" relationships with
> various other objects.   Why then, should we not use multiple inheritance
> when modelling such relationships?

Because it doesn't work in practice? I'm serious here. One of the
things we would like to do is eliminate the disconnect between
modeling and implementation, and the naive views of inheritance
relations that are common in elementary textbooks frequently
have very serious problems when you actually try to do anything
with them.

If I wanted to model something that had multiple diverse
roles, I'd pick some mechanism other than inheritance, and
expect the actual implementation to have a number of objects
that handle the diverse roles of "electrical-device", "depreciable-asset,"
and "personal-property," with the appropriate linkage so that
they all refer to the same conceptual object.

> One major reason why multiple inheritance has such a bad name can be
sheeted
> back to the brain-dead way in which C++ implements it.

Implementation has nothing to do with it.

> The other main
> reason is that inheritance itself, single or multiple, implementation or
> interface, is _way_ overrated as a code structuring technique.  This is
> probably due to it not even being consistently defined - it seems to mean
> different things to different people at different times (depending on
which
> language they're currently working with).

And if you want transparency in your implementation as well
as a domain model you can actually use, you have to live within
the limitations of your technology. That means that inheritance
is implementation inheritance, and any other definition is simply
academic pie-in-the-sky arm waving. If you want to do something
other than implementation inheritance, you find some way of
modeling it which will map cleanly into the technology.

> IMHO, inheritance only works robustly in the face of change if you can
> guarantee that the potential instances of your (sub)classes form a strict
> proper subset (mathematically speaking) of the potential instances of
their
> ancestor classes.  afaik, which is not terribly far really
> ;-) , there is no OO language on earth that can _guarantee_ this subclass
==
> subset relationship for you - you have to arrange it yourself (somehow).

And that's one of the conceptual pitfalls. A mathematician would
look at the behavior of a subclass as having ***less*** functionality
than the superclass, while in practice subclasses usually have either
*different* functionality or *more* functionality.

So we're back at the naive definition does not match the
implementation reality.

> Other folk have also suggested that in order to properly achieve the
above,
> you need to follow the rule: "only abstract classes can be subclassed".
> That is, if you want to create class B as a subclass of class A, and A is
> not already an abstract class, you should create a third class A', which
> _is_ an abstract class, and have both class A and class B inherit from
that.
> For a far better explanation of this and many other related issues I refer
> the interested reader to:
>
>      http://okmij.org/ftp/Computation/Subtyping/Trouble.html
>
> my $A0.0148,

That's just confusing the issue. The Law is that any subclass
should be usable when the user expects a superclass. I believe
that's called the Liskov Substitution Principle, and it's the only
thing you need to remember.

The moment you try to mix two classes that have the same
name for two different concepts, you're dead.

John Roth
>
> gary
>