Re: Sigh. In Defense Of Inheritance Tyler Close (tyler@lfw.org)
Sun, 25 Oct 1998 08:22:15 -0500

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