customizable equals/hashCode for Maps/Collections

[GoogleCodeExporter]

TreeMap has the advantage that one can specify which objects are equal
using a Comparator.

It would be useful to be able to specify this for HashMaps and generally
all collections that work with equals/hash

public interface Equalator/Equator<T> {
  boolean equals(T left, T right);
}
public interface Hasher<T> extends Equalator<T> {
  int hashCode(T t);
}

Apache collections allows you to override AbstractHashedMap.hash/isEqualKey
- which is similar.

Original issue reported on code.google.com by zeitlin...@gmail.com on 10 Jun 2009 at 7:54

[GoogleCodeExporter]

We have an experimental version of this internally.  It has a single interface 
with
both methods, called Equivalence.  We have not yet found it to be highly 
useful. 
It's the kind of thing that does have legitimate uses, but more people use it 
badly
than well.  Still, this could eventually work its way out.

Original comment by kevin...@gmail.com on 10 Jun 2009 at 3:43

[GoogleCodeExporter]

A discussion on Artima brought this up (in the discussion).
Basically, it's hard to write an equals method that is both correct and useful.
Therefore, it's easier to be able to provide one where needed.

http://www.artima.com/lejava/articles/equality.html

Original comment by zeitlin...@gmail.com on 11 Jun 2009 at 7:25

[GoogleCodeExporter]

Dot Net has something similar:

http://msdn.microsoft.com/en-us/library/ms132151.aspx (IEqualityComparer<T>)

and its default implementation, EqualityComparer<T>.Default

http://msdn.microsoft.com/en-us/library/ms224763.aspx

The default implementation will use IEquatable<T>.Equals(T other) if T 
implements 
IEquatable, otherwise it will use Object.Equals(Object other).

All Dot Net collection implementations that use a hashcode (Dictionary<TKey, 
TValue> 
and HashSet<T>) take an optional constructor argument allowing an 
IEqualityComparer 
to be specified (in the same way that SortedSet and SortedMap implementations 
in Java 
can take a Comparator as a constructor argument).

Having used the Dot Net version, I would suggest changing the names of the 
methods so 
that they aren't overloads of Object.equals and Object.hashCode .  Maybe 
Equivalence<T>.areEqual(T, T) and Equivalence<T>.hashCodeFor(T) ?

Original comment by Ben.Lings on 17 Jun 2009 at 11:54

[GoogleCodeExporter]

Implementations need not be exposed, so it wouldn't be too much bloat. I think 
you
just need:
- the Equivalence interface
- static factory methods taking an Equivalence and a backing Collection/Map

If you want, you can add a constant Equivalence implementation using reference
equality, defined as a singleton constant in the Equivalence interface so as 
not to
expose that class either.

Original comment by ray.a.co...@gmail.com on 3 Aug 2009 at 8:03

[GoogleCodeExporter]

I had a conversation here about this a year ago (about Equators - either 
mailing list 
or issue), but I can't find it.

I created an issue for this at apache commons collections: 
https://issues.apache.org/jira/browse/COLLECTIONS-242
The checked in version is at 
http://svn.apache.org/viewvc/commons/proper/collections/branches/collections_jdk
5_bra
nch/src/java/org/apache/commons/collections/functors/Equator.java?
revision=643590&pathrev=643590

As in that ticket, there are times you want to equate objects under a different 
mechanism, and a number of new possibilities emerge - one of my highest use 
ones 
being an EquatableSet, which allows a "T get(Object equals)" type method, where 
an 
object that is equivalent under the Equator is able to be retrieved in a map 
style 
fashion.

Original comment by stephen....@gmail.com on 10 Aug 2009 at 4:27

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 13 Aug 2009 at 2:49

• Changed state: Accepted
• Added labels: post-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:45

• Added labels: Milestone-Post1.0
• Removed labels: post-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved