advice on programming style: is multiple inheritance bad?

[Uwe Mayer]

Irmen de Jong wrote:

>From C++ and Java we "learn" that you shouldn't do that.

>  From C++? Didn't think so... C++ is perfectly capable of
> multiple inheritance. Or do you mean that you can get into
> trouble quickly because of the various access levels,
> virtual base classes etc?

That was a stupid sentence from me, sorry. On a lecture on software
engeneering I was tought that multiple inheritance was a bad thing to do,
since there are problems with the resolution order which leads to badly
readable code, induces errors, shows poor software design, etc.
I see the point in that. Their most favourite programming language is Java
which doesn't support m.i. anyways.
When writing the sentence above I was implying that m.i. in C++ propably is
difficult to handle (though I never programmed much C++) and then Java,
being a more modern programming language, abandoned m.i. in favour for
interfaces.

The problem I was working on in the first mail is written in PyQt, a Qt
extention for Python.
There you create your base classes in the Qt Designer. Functionality is
added by subclassing the base class and overriding the appropriate methods.
Since you then *have* to subclass from your Qt-Designer-base-class you're
alreade done once with inheriting.

BTW: when doing m.i. you can't mix new-style and old-style objects, or else
Python exits with a Segmentation Fault. :)

The second base class I am using implemented something like the Qt SIGNAL
and SLOT mechanisme (observer design pattern). This is perhaps rather a
"uses" or "can do" relationship than an "is a" relationship. I should have
delegated the signalling capabilities to another object, rather than to
inherit from it. However, I would have had to introduce a new instance
variable to delegate work to and all other objects relying on that
interface would have to be made aware of it.
To do this I could again introduce accessors... hmmm - I think I got to
think this over.

How much effort is it worth to keep up good transparent programming design
at cost of more code, more levels of delegation (slower) and a more complex
interior in general?

Ciao
Uwe