Inheritance Considered Harmful

[Tyler Close]

At 10:49 AM 10/23/98 -0700, you wrote:
>OK, we are all agreed about the value of Inheritance.  Now who's going to
>write the paper, and where are we going to try to get it published.

If you think it's worthy of a paper and know how to get it published, I
would be more than happy to write it.

>GUI toolkits seem to make heavy use of inheritance.  We should probably
>think of what a no-inheritance GUI would look like.

I have already written a no-inheritance GUI library. This is the same GUI
library that I was talking about earlier in the multithreading debate.

>On the other hand, it is quite useful in Java to know that every object has
>a toString() method.  (And somewhat bogus to know that it also has wait()
>and notify() methods.)  The equals(Obj foo) and hashCode() methods are also
>somewhat questionable.  The getClass(), and finalize() methods are somewhat
>Java specific, one being a not bad idea, and the other one being poorly
>thought out at best.
>
>The clone() method is weird.  It is defined to throw an exception unless
>the class implements the Cloneable interface.  It sounds like a hack to
>give programmer control over access to a native method.

So long as the language is not strongly typed, none of these are necessary.

If you pass an object to a method that expects its arguments to have a
toString() method, then you just make sure that it's got one. If you never
intend to pass the object to such a method, then you don't need this method.

For now, I'll omit my blazing disgust at the list of methods that Java put
in the Object class.
  
>On the other hand, yesterday I worked around a bug in Java's
>PipedInputStream by subclassing.  The workaround allows us to ship a
>working program within our "ship only unmodified Java" license.

The no-inheritance solution to this is to create a class that implements
the InputStream interface by delegating the non-buggy calls to a
PipedInputStream object.

Tyler