On Thursday, Sep 11, 2003, at 15:59 US/Pacific, Richard A. O'Keefe  
wrote:

> Dustin Sallings <dustin at spy.net> appears to have misunderstood me
> rather seriously:
>
> 		That's a different model.  Source code is not required
> 	for extending classes in Java.  Vector is a stable (though old
> 	and what should be considered deprecated) API that can certainly
> 	be extended.
> 	
> It isn't *JAVA* that needs the sources if you want to extend it,
> it's the *PROGRAMMER* who needs the sources.  There can be important
> information about a class, such as a class invariant, stated as plain
> comments, not Javadoc comments.

	Your point only seems valid if an API has misleading documentation and  
was not written to be reused.

	The message to which I responded suggested that it required detailed  
knowledge of the implementation of a class in order to extend it.  You  
further seemed to imply that the only way to acquire knowledge deeply  
enough to do this is by reading the sources.

	This just isn't true.  Classes that are designed to be extended don't  
require knowledge of the source to extend them.  Extending classes that  
are not designed to be extended is asking for trouble, although you did  
imply that you would be required to read the source for each JVM in  
which your class was deployed, that's not very practical.  What is not  
part of the public (or protected) API is subject to change.

> I note that *nothing* in the Java 2se 1.4.1 JavaDoc page for Vector
> says that it is deprecated, *nothing* in the 1.4.1 "Deprecated API"
> web page says it is deprecated, and on the contrary, in 1.2 it was
> fitted into the 1.2 Collections framework.

	I said it should be considered deprecated, not that it is.  ArrayList  
is generally more appropriate nowadays, but this isn't exactly  
on-topic.  For further reading:

	http://saloon.javaranch.com/cgi-bin/ubb/ 
ultimatebb.cgi?ubb=get_topic&f=34&t=000684

> There are one or two important things that someone extending Vector  
> needs
> to know which are NOT in the JavaDoc page; for anything that really  
> needs
> "isa Vector" rather than "hasa Vector" you as a programmer do in fact
> need to read the source code to be sure you've got it right, even  
> though
> the Java *compiler* doesn't need the source code to believe you.

	I don't understand where you get this ``fact'' that you have to read  
the source.  I extended both Hashtable and HashMap from documentation  
to track access times.  I'm curious as to what these ``one or two  
important things'' that must be known for extending, but are not in the  
documentation are.
	
> 		If you want to override Vector to print itself with the
> 	size, I don't have to know everything about Vector, I just have
> 	to do this (no, this isn't *exactly* how I'd do it):
>
> 	public class MyVector extends Vector {
> 	    public String toString() {
> 		return "{MyVector with " + size() + " elements}");
> 	    }
> 	}
>
> Yes, but that was a trivial example.  Even if you had used  
> 'elementCount'
> instead of size(), you would still have been covered by the  
> documentation.
> There are things to know about Vectors (and other Collections) that  
> are not
> quite covered in the documentation.  (Although I must say that the  
> 1.4.1
> documentation is better than some of the older documentation I was  
> using.)

	elementCount is an example of a API design mistake that is part of the  
reason Vector isn't recommended for use anymore.  It's a bad API.  A  
bad API for subclassing is similar to a bad API for usage.  The Law of  
Leaky Abstractions applies to both.

> Obviously you could extend _any_ class with a method which only used
> public methods to achieve its effect; that tells us nothing.

	Similarly, you could use any API as a client the way it was intended  
to be used without reading the source, but if you want to do things  
that the API was not designed to do, then I agree, you have to read the  
source to make these modifications.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin at spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________