Re: Clashing Interface methods
rossum wrote:
I am trying to write my own queue, based on a Hashtable:
public class HashQueue<E>
extends Hashtable<Integer, E>
implements Queue<E> { ... }
Hashtable should be discarded in favor of HashMap whenever possible.
Also, is a HashQueue really a hash table? Probably not. Favor
composition over inheritance.
This combination beings in interfaces Collection, Map, Dictionary and
Queue. I am having problems with the method remove(). There are
different versions with different return values in the various
interfaces:
Queue has: E remove()
Collection has: boolean remove(Object o)
Dictionary has: E remove(E elem)
Generics are thorny issues. Technically speaking, there is nothing
forbidding the three implementations at bytecode level, but at the JLS
level, it appears that since the two remove methods have the same method
arguments after erasure, the last two methods cannot coexist.
The Queue version has a different signature to the other two so that
is not a problem. My problem is that the compiler is telling me that
the Dictionary remove does not match the Collection remove return
value and vice versa. It seems that the compiler is treating Object
and E as the same. How can I tell the compiler which of my
implementations of remove belongs to Collection and which to
Dictionary? I have tried Collection.remove and (Collection)remove but
neither work.
Whenever method hiding occurs, the resolution is:
((RandomClass)obj).method()
but that can only be done at method invocation.
A short example:
interface FileStuff {
String read();
}
interface ConsoleStuff {
int read();
}
class Stuff implements FileStuff, ConsoleStuff {
public String read() { return "Hello World!"; }
// public String FileStuff.read() { return "Hello World!"; }
// public String (FileStuff)read() { return "Hello World!"; }
public int read() { return 42; }
}
Is there a way round this problem?
No. Not in Java, not even in C++ (which has thornier issues relating to
multiple inheritance) AFAIK.
Thanks in advance.
rossum
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth