Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: equals(), Sets, Maps, and degrees of equality
Date: Thu, 10 Nov 2011 20:58:38 -0500
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <j9hvhf$r4p$1@dont-email.me>
References: <24123649.762.1320892382934.JavaMail.geo-discussion-forums@vbmh5> <j9ffe1$3k9$1@dont-email.me> <j9frqs$pbk$1@dont-email.me> <663d43b1-2c58-40ea-90d5-d46b8ae821e5@cc2g2000vbb.googlegroups.com> <j9gq5d$ue6$1@dont-email.me> <5a705514-4b5e-48c2-8984-83e3b62b23b9@y7g2000vbe.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Nov 2011 01:59:11 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="HSlJAUb3pGXi3i7ZL/HoAw"; logging-data="27801"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nkJxfAV8ZQhu8/rUUZ+j3"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
In-Reply-To: <5a705514-4b5e-48c2-8984-83e3b62b23b9@y7g2000vbe.googlegroups.com>
Cancel-Lock: sha1:gPEO+KMLK0d83iOdeSVscXSp3ww=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9840

On 11/10/2011 10:29 AM, Sean Mitchell wrote:
> On Nov 10, 10:21 am, markspace<-@.>  wrote:
>
>>> Possible, but I could see a lot of concurrency issue arising. Might
>>> work well in a single threaded application.
>>
>> What?  Why?  There's no concurrency issues there.  There's no state
>> beyond what is in the Dog object.  Method call != concurrency issue.  In
>> fact it's the opposite, method calls are inherently thread safe.
>>
>> If you need concurrency, you add it to the Dog object.
>
> Maybe I don't understand what you are proposing. It sounds like you
> want a singleton wrapper, into which I stuff my Dog, before I put him
> into my Set/Map.

     I think "concurrency issues" might not be the best description,
but there are certainly drawbacks to markspace's suggestion.  Back
to your original post: You wanted a Dog whose breed (only) would
govern its membership in a Set<Dog> but whose name (only) would
matter for a Map<Dog,Owner>.  markspace's idea of endowing each Dog
with a DogComparisonStrategy wouldn't work if the same Dog instance
could be a member of the Set *and* a key in the Map: You'd need to
visit every Dog and reset its DogComparisonStrategy before doing
any operation on either the Set or the Map.  (Strictly speaking,
you'd only need to visit the Dogs that participated in the relevant
data structure -- but since it would be at best dubious to traverse
a Set or Map whose Dogs were in the wrong state you'd need a third
Collection<Dog> that would not use the DogComparisonStrategy at all.)

     The notion of making Breed and Name inner classes of Dog seems
more and more attractive:

	class Dog {
	    class Breed { ... };
	    class Name { ... };
	    private Breed breed;
	    private Name name;
	    ...
	}

The wrapper approach could also work, and would be necessary if Dog
weren't alterable:

	class Dog {
	    private String name;
	    private String breed;
	    ...
	}

	class DogByBreed {
	    private Dog dog;
	    ...
	    public int hashCode() {
	        return dog.getBreed().hashCode();
	    }
	    ...
	}

	class DogByName {
	    private Dog dog;
	    ...
	    public int hashCode() {
	        return dog.getName().hashCode();
	    }
	    ...
	}

-- 
Eric Sosman
esosman@ieee-dot-org.invalid