Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: idea for more efficient HashMap
Date: Sun, 20 Jan 2013 14:49:55 -0500
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <kdhhp6$dil$1@dont-email.me>
References: <9hc2f8ltgn1bmdsrk8vb9kuu1vi5dkl2r5@4ax.com> <50f4ef8e$0$80160$742ec2ed@news.sonic.net> <1d8355c1-4128-4920-9430-3a253e768cab@googlegroups.com> <50F7C307.7060407@telia.com> <50f8c1f2$0$80125$742ec2ed@news.sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 20 Jan 2013 19:49:58 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="13909"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18vDs5r6yArMaMjdOrPf6fw"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
In-Reply-To: <50f8c1f2$0$80125$742ec2ed@news.sonic.net>
Cancel-Lock: sha1:+bBGwBRNvPub8bG9cBhO28EU77I=
Xref: csiph.com comp.lang.java.programmer:21589

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