A Comparator, but for hashing

Question

Hi
When comparing classes in sorted sets, it is possible
to define different ways to compare instances by using
the class Comparator. I use this often since the same
classes can be compared differently. However, I would
like to do the same with respect to equals(...) and
hashCode(..), ultimately using it in classes like
Hashtable.
Do anyone know if there is going to be support for
different ways of equality in SDK in the near future?
Is it possible to 'vote' for these changes?
Thanks
P�r

Answer 1

dubwai, I am not sure if I understood what you meant
when you wrote
Allowing a Collection to determine it's ownbehavior
doesn't smell. Relying on the Objects in theCollection
to do so smells a little. I think that's is whythis
a persistent question.Please, can you elaborate.In this and other threads it has been suggested that using a third Object to determine the equality of two others has a 'smell'.
http://en.wikipedia.org/wiki/Code_smell
The claim is that this violating the OO principle that an Object determines it's own behavior. I am arguing that it's quite the opposite and that the current situation is violating that same principle. For example, a HashSet doesn't allow duplicates. What determines whether the Objects are duplicates? The Objects that are being added.
But the bevhavior in this case is whether two given Objects can be in the container at the same time. The owner of that behavior is the HashSet, not the Objects being added. Why should a Collection be forced to ask it's contents what it should and shouldn't allow? I argue it shouldn't. It should be up to the container to determine whether two given Objects should be allowed to coexist inside it. This is what a Comparator allows and is what an Equalator would allow if it were part of the JDK.
So IMO, it's Object.equals() that has a smell, not Equalators.