JDK-4771660 : (coll) Comparator, Comparable, Identity, and Equivalence
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 1.2.1,1.4.2
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_8,windows_xp
  • CPU: generic,x86
  • Submitted: 2002-10-31
  • Updated: 2017-06-15
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The Object methods equals and hashValue define an equivalence relation
among objects. Similarly, the Comparable method compareTo defines an ordering.

The Comparator interface defines a way to impose an external ordering among
objects.  Why isn't there similarly a way to impose an external equivalence
relation among objects?

I have some nontrivial applications in which I'd like to look at a set of
objects from different points of view (that is, under different equivalence
relations at different points in my code), but the absence of an externally
imposable equivalence relation forces me to wrap all the objects in order
to view them under a different equivlence relation.  If I'm lucky then the
two default equivalence relations (identity and natural) may be just what I
need, but I suspect not.

If there were an externally imposable equivalence relation, it would be
an interface with two methods:
     interface Equivalence {
	int hashValue(Object);
	boolean equals(Object, Object);
     }

Two standard (and trivial) instances would be provided: the identity
equivalence relation and the natural equivalence relation.

I believe separating things this way makes it much easier to have a number
of interesting variants on maps and sets without providing wholly new
implementations.  If the constructors are static factories, we would still
have the flexibility to fully specialize the implementation for performance
when one of the two standard equivalence relations is given to the static
constructor.

This kind of functionality can be added without making any of the existing
classes obsolete.

Comments
EVALUATION > The Object methods equals and hashValue define an equivalence relation > among objects. Similarly, the Comparable method compareTo defines an ordering. > > The Comparator interface defines a way to impose an external ordering among > objects. Why isn't there similarly a way to impose an external equivalence > relation among objects? We wanted to avoid the complexity. We seriously entertained this notion at the time the collections framework was designed, but rejected it. The power-to-weight ration seemed to low. We felt that equals was what you wanted 95% of the time; ==, 4%; and something else 1%. Writing sensible contracts for bulk operations when is very tricky when equality predicates differ. > I have some nontrivial applications in which I'd like to look at a set of > objects from different points of view (that is, under different equivalence > relations at different points in my code), but the absence of an externally > imposable equivalence relation forces me to wrap all the objects in order > to view them under a different equivlence relation. Yes, I admit that this is a pain in the butt. > If I'm lucky then the > two default equivalence relations (identity and natural) may be just what I > need, but I suspect not. I'd be curious to know more about the application (preferably in person rather than by e-mail). > If there were an externally imposable equivalence relation, it would be > an interface with two methods: > interface Equivalence { > int hashValue(Object); > boolean equals(Object, Object); > } Yep. I'm not sure I'd call it "Equivalence," but I'm not quite sure what I'd call it. Perhaps EquivalenceRelation, or EqualityPredicate? (Neither of those names are any good either.) > Two standard (and trivial) instances would be provided: the identity > equivalence relation and the natural equivalence relation. > I believe separating things this way makes it much easier to have a number > of interesting variants on maps and sets without providing wholly new > implementations. If the constructors are static factories, we would still > have the flexibility to fully specialize the implementation for performance > when one of the two standard equivalence relations is given to the static > constructor. > > This kind of functionality can be added without making any of the existing > classes obsolete. > > What do you think? See above. I suppose I could be convinced otherwise by compelling examples. We should also involve <###@###.###> in these discussions.
2004-09-08