Re: idea for more efficient HashMap
On 1/17/2013 10:30 PM, Kevin McMurtrie wrote:
[...]
My original point is that you can't gracefully enforce insertion of an
object having the key, value, and collision link together when put(K,V)
takes two arguments. It's unfortunate that Dictionary defines setter
methods. There are so many cases where I want a widely supported
implementation of V get(K) without the other things. Maybe if interface
compatibility was more flexible it wouldn't be a problem.
One approach would be to write a class implementing the
Map<K,V> interface, but whose put(K,V) method throws an
exception (just as an UnmodifiableMap's does). Sketch:
interface Mappable<K,V> {
K getKey();
V getValue();
Mappable<K,V> getNext();
// ...
}
class Mapping<K,V> implements Map<K,V> {
@Override
public V put(K key, V value) {
throw new UnsupportedOperationException();
}
// Not an @Override
public void put(Mappable<K,V> entry) {
// ...
}
// ...
}
True, run-time instead of compile-time detection of the use
of an unsupported method is not exactly graceful, but there's
certainly precedent. (Maybe you can @deprecate the put(K,V)
method; off-hand I don't know whether that works with a method
that's not deprecated by its interface -- and even if you can,
that only provides a compile-time guard for explicit uses of
the Mapping class, not for references via its Map interface.)
--
Eric Sosman
esosman@comcast-dot-net.invalid