Re: Set and .equals() semantics

From:

"Mike Schilling" <mscottschilling@hotmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 8 May 2008 15:56:22 -0700

Message-ID:

<dyLUj.623$8i5.518@flpi144.ffdc.sbc.com>

"Mark Space" <markspace@sbc.global.net> wrote in message
news:U4JUj.2702$3O7.1685@newssvr19.news.prodigy.net...

Rex Mottram wrote:

which can both look up and retrieve a reference. But I hope I'm
misunderstanding something which would allow me to use the more natural
Set design.

Nope, I think I agree. Set and subclasses could benefit from a "find()"
method which does an equals() or hashcode() lookup as appropriate and
returns the element already in the set.

That is, every set should build a hash table of its contents whether it
needs one or not? I disagree. (Though it would be trivial to add find()
specifically to HashSet, which is implemented on top of HashMap.)

What could be useful is an adapter class to provide find() to a Set,
something like

    public class LookupSet<T> implements Set<T>
    {
        private Set<T> underlyingSet;
        private Map<T , T> map;

        public LookupSet<T>(Set<T> underlyingSet)
        {
              this.underlyingSet = underlyingSet;
              map = new HashMap<T, T>();
        }

        public T find(T key)
        {
             return map.get(key);
        }

        // Forward all Set calls, modifying the map as need be
}

Not that this is hard to build yourself.