Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!nx01.iad01.newshosting.com!newshosting.com!216.196.98.142.MISMATCH!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe03.iad.POSTED!00000000!not-for-mail
From: Owen Jacobson <angrybaldguy@gmail.com>
Newsgroups: comp.lang.java.programmer
Message-ID: <2011110922100694284-angrybaldguy@gmailcom>
References: <24123649.762.1320892382934.JavaMail.geo-discussion-forums@vbmh5>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: equals(), Sets, Maps, and degrees of equality
User-Agent: Unison/2.1.5
Lines: 42
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 10 Nov 2011 03:10:05 UTC
Date: Wed, 9 Nov 2011 22:10:06 -0500
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9815

On 2011-11-10 02:33:02 +0000, Sean Mitchell said:

> Anyone ever run into the case where you wish an Object could have more 
> than one equals(), or that Set and Map implementations would let you 
> pass in something like a closure to determine key equality?

Given the lack of anything sufficiently "like a" closure, until Java 8 
if not later, you'll have to live with the options you have.

> It seems to me that objects can be equal in varying degrees. Let's 
> consider a class Dog:
> 
> public class Dog {
>   String breed;
>   String name;
>   String age;
> }
> 
> I may want to have a Set<Dog>, which holds only one Dog of each breed, 
> irrespective of name of age. In this case my equals()/hashcode() would 
> only consider breed.
> 
> But I may also want a Mag<Dog, Owner> in which each Dog is made unique by name.
> 
> And of course, there is the most intuitive case where I want to use 
> equals() to see if the instances map on all three fields.
> 
> I suppose I could create a wrapper class for each purpose which only 
> overrides equals() and hashcode(), but that seems very unsatisfying and 
> inefficient.

That's one option, and it's not as inefficient (at least in terms of 
run time) as you might expect, unless you have several million wrappers 
kicking around. It's clunky to write, true.

Another option is the TreeSet and TreeMap classes, which have slightly 
worse lookup and insertion complexity guarantees (amortized O(log n) vs 
amortized O(1) on lookup, for example) but allow passing a Comparator 
that also controls equality tests for that set or map.

-o