Sigh. In Defense Of Inheritance

[Tyler Close]

At 04:35 PM 10/24/98 -0700, you wrote:
>programmer), I have to say, all my experiences with single inheritance have
>been pleasant, even joyous, whatever the theory may say. And judging from

Try something for me. Go back and look at the code you have that uses
single inheritance. How much of it is inheritance and how much of it is
just interface implementation? Of the code that is inheritance, ask
yourself what it would mean to change it to interface implementation. Is
the result better?

>what I read of
>Java programmers in general, the world at large considers single
>inheritance to be just plain good. Therefore, discarding it is a very

I don't know how to argue against this governing by opinion poll. My poll
indicates that people will grumble and then realize that this is what they
have been leaning towards all along.

>Tyler has already demonstrated just how difficult it will be to persuade
>people to give up threads. So from a marketing perspective I think that
>discarding threads is a bad idea. Nevertheless I agree that threads must be
>discarded, because for secure distributed reliable systems with mutual
>suspicion, it is a matter of desperate importance.

I don't mean to be stubborn, but could someone just write down a point form
list of the reasons for this. I understand that deadlock is a bad program
bug, but I don't see how the string of adjectives comes into play. Right
now, my understanding is at a point where your above statement could be
summarized as: "Threads must be discarded, because for God, it is a matter
of desperate importance."

>are now familiar with inheritance, it seems unlikely (in fact wildly
>improbable) that they are far enought along the curve of experience to agree
>with combined intellectual might found in this email list. In other words,
>I'd bet they still like it, a whole lot, just as I do.

I'd bet they still don't understand it. I'd bet they'd be pretty smug to
find out that they had cleverly circumvented a pot hole that their richer
cousins had gotten hopelessly mired in. I'd bet they don't like learning
curves and would be happy to see someone dynamite it.

>
>Jonathan made 2 arguments that together almost bring me across the distance
>to agreeing with everyone:
>
>1) Inheritance opens up the possibility of "leaking" capability, an obvious
>problem for secure computing;
>2) It is easier to add inheritance later than it is to remove it.

Well, this is the same point of view that Ping presented and that I
responded to. I've covered many more and many more important points than
just the above two. I guess I'll summarize here:

1. Inheritance encourages the designer to widen an object's interface.
2. Inheritance encourages the designer to use complex language syntax to
bundle many objects into one.
3. Inheritance camouflages the fact that an object's interface is getting
too large.
4. Inheritance encourages white box reuse that can cause both super and sub
classes to be corrupted.
5. Inheritance camouflages delegation.
6. Inheritance, with its access protections, can make it impossible to
apply certain design patterns to solve problems.
7. Inheritance encourages the construction of complex, overly restrictive
class taxonomies.
8. Inheritance lessens the designer's focus on object interactions.

If E has inheritance, I'm going to be pretty tempted to create a language
without it. I imagine others will be too. Sounds like a recipe for infant
death syndrome to me.

>If this very high standard of delegation simplicity cannot be met, I urge

See, you're missing the point. The "very high standard of delegation
simplicity" is a big part of what makes inheritance bad.

>deploying E with inheritance. Kill only one white elephant per language, or
>the elephants will kill you.

I don't know about these crowd control tactics, but my gut tells me that
people will go for simpler every time.

Tyler