Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21589

Re: idea for more efficient HashMap

Show key headers only | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

idea for more efficient HashMap Roedy Green <see_website@mindprod.com.invalid> - 2013-01-12 01:55 -0800
  Re: idea for more efficient HashMap v_borchert@despammed.com (Volker Borchert) - 2013-01-12 14:21 +0000
  Re: idea for more efficient HashMap Robert Klemme <shortcutter@googlemail.com> - 2013-01-13 19:44 +0100
  Re: idea for more efficient HashMap Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-14 21:56 -0800
    Re: idea for more efficient HashMap Robert Klemme <shortcutter@googlemail.com> - 2013-01-16 14:31 -0800
      Re: idea for more efficient HashMap Lars Enderin <lars.enderin@telia.com> - 2013-01-17 10:23 +0100
        Re: idea for more efficient HashMap Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-17 19:30 -0800
          Re: idea for more efficient HashMap Robert Klemme <shortcutter@googlemail.com> - 2013-01-20 20:28 +0100
          Re: idea for more efficient HashMap Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-20 14:49 -0500
          Re: idea for more efficient HashMap Roedy Green <see_website@mindprod.com.invalid> - 2013-01-29 01:41 -0800
            Re: idea for more efficient HashMap Arne Vajhøj <arne@vajhoej.dk> - 2013-01-29 22:03 -0500
              Re: idea for more efficient HashMap Gene Wirchenko <genew@telus.net> - 2013-01-30 11:34 -0800
                Re: idea for more efficient HashMap Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 21:35 -0500
                Re: idea for more efficient HashMap Gene Wirchenko <genew@telus.net> - 2013-01-31 10:47 -0800
                Re: idea for more efficient HashMap Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 19:57 -0500

csiph-web