Re: equals(), Sets, Maps, and degrees of equality
Sean Mitchell wrote:
....
I think, fundamentally, that is the problem. I don't think that Dog
or any subclass of Dog should have to be in any way concerned with
how I want to use him in a collection. Although IMO it is reasonable
for Dog to know whether or nor he is the same as another Dog in all
the ways that are important to Dogs.
The core of the issue for me is that the most commonly used
implementations of Set (possibly Map was a poor example, as has been
illustrated by Andreas and others) rely solely on the object's
equals() to determine equivalence.
The core of the issue is that you want to use the wrong entity as your key.
The fault, dear Brutus, lies not in our 'equals()' method but in ourselves.
TreeSet will take a Comparator as pointed out, and so probably this
is good enough, but it seems a little hackish to use a Comparator,
and a SortedSet to solve a problem of equality (or perhaps,
equivalency).
"Seems"? That's a pretty subjective statement without any engineering basi=
s. What is "hackish"? That is the standard solution and why 'Comparator' =
exists in the API. The burden of proof is on the one claiming "hackishness=
", along with the burden of definition for such a vague, subjective term, e=
specially when paired with the hand-waving, responsibility-ducking "seems".
I'm here to tell you, there's nothing hackish about using a 'Comparator'. =
That's a strange sentiment coming from someone who wants to hackishly use t=
he 'Dog' class for a key where he means 'Breed'. Maybe if your model wasn'=
t so tangled and illogical you'd have an easier time of it.
--
Lew