C++ (was RE: Python suitability)

[Eric Langjahr]

Well inheritance has MANY potential issues which have been explored 
extensively in the OOP community.  Composition is certainly preferable
in many cases.

Some people have described one aspect of the inheritance problem as
the "YO-YO" effect.  Inheritance has also been called, by some, the
goto statement of the 90's

The problems exist, to some extent, regardless of the specific OOP
language.  Now some OOP environments have better tools for browsing
class hierarchies and so forth, but still that is only a partial
solution.

The basic problem is that it can be VERY hard to follow the flow of
control in a very deep inheritance tree as method calls go up and down
the tree.  It can be even harder to subclass from this tree and
override or redefine (whatever your terminology) without producing all
sorts of unintended side effects (some of which may or may not show up
immediately).

In fact, from a strictly theoretical level, I think that Eiffel makes
the only real attempt to solve this problem to some extent with Design
By Contract concepts.  While it doesn't solve the problem of
understanding the hierarchy it does help to avoid producing unintended
side effects IF the contracts are well thought out to start with.

Fifteen years ago I would have insisted that inheritance was a KEY
element of any OOPL.  But now I am not so sure that this is really so.
At least NOT the way it is implemented in most 'main stream' OO
languages.

In MANY cases I think programmers use IMPLEMENTATION
inheritance simply because they lack BETTER tools to solve the code
reuse / laziness / redundancy problem.   MACRO facilities, genericity,
and case programming environments (with a little 'c') could solve many
of these problems better.  Unfortunately the case tools I envision
don't exist YET.

Instead we have terrible 'object-oriented' application frameworks that
often offer little real benefit.  In many cases programmers would be
better off using the old C starter application of the sort that was
very common 10-15 years ago in Windows and Macintosh world than 
trying to fit square pegs into round holes.  These 'oop' frameworks
are, in many cases, worthless if your application needs to do much
that is very different from what the implementor had in mind.   In
many cases, the companies producing these frameworks don't even use
them for most of the software they produce.  I find that
interesting<g>.

IMHO our industry, and programmers, tend to follow trends and the
'latest' fad to a far greater extent than even society as a whole.

Still all comes down to choosing the right tool for the right job.

Apologies if I have drifted a bit off topic<g>

On 15 Dec 1999 20:51:04 GMT, boud at rempt.xs4all.nl (Boudewijn Rempt)
wrote:

>Alex Martelli <Alex.Martelli at think3.com> wrote:
>> Grant writes:
>
>>> About twice as long as it would take for a Modula-3 or
>>> Smalltalk programmer.  ;) I've never thought C++ was a
>>> particularly decent example of an object-oriented language, but
>>> maybe that's because I learned Smalltalk and M3 first.
>>> 
>>> The whole virtual-function-method thing has always struck me as
>>> very obtuse.  You apparently have to guess ahead of time which
>>> methods somebody might, at some point in the future, want to
>>> override, and declare them differently from the non-overridable
>>> ones...
>>> 
>> Or, to put it another way: you have to DESIGN, rather than
>> just start hacking.
>
>> Specifically, if you follow the advice of Scott Meyers, in his
>> excellent "Effective C++" (CD Edition): never inherit from a
>> concrete class.
>
>That makes C++ about as powerful as Visual Basic - in essence,
>no inheritance at all, just interfaces... Having just done a
>large project in Visual Basic, I've learnt how painfult that
>limitation can be - and I was kind of surprised when I read
>in Design Patterns that composition should be favoured over
>inheritance. There are no doubt good reasons, but not one
>I can think of.
>
>Boudewijn Rempt  | http://denden.conlang.org