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.