I like the type class approach: interface Equal<A> { boolean eq(A a, A b); }
Then wherever you need to be able to compare two objects you need to make sure you have an Equal<SomeType> around. You can use this to control 'which meaning' of equality is applied. interface Hash<A> { hash(A a); } Same thing but for hashcodes. Of course, this won't really help with existing libraries that depend on equals(Object), but I can't fault the idea. The Functional Java library has Equal and Hash, similar to the above but as abstract classes with lots of convenience methods. It also has a number of collections that use those types. I just realised my name's at the top of the Javadoc, which is odd as I've made one commit ever, which I think was to fix a typo. :) On Sun, Oct 17, 2010 at 7:06 AM, Reinier Zwitserloot <reini...@gmail.com> wrote: > For those who DONT know why equals() is really complicated, scroll to > the end for an explanation. Without knowing about it this post is > probably not going to make much sense. If you understand why a > hypothetical "ColoredList extends ArrayList" class, which adds a color > property to any list, MUST have an equals implementation that says > that a red empty list is equal to a blue empty list, even though that > seems silly, you don't need to read the footnote. > > What we really need is for AbstractList's equals() method to be > intelligent enough to realize if 'other' is a subclass of AbstractList > that isn't adding any state that is relevant for equality, in which > case it can do its comparison as usual, or, if 'other' is a subclass > that DOES add state relevant for equality, such as a color property. > If that is the case, AbstractList's equals method should conclude > immediately with: Not equal, even if the contents are. > > A few people have proposed such a system, including a somewhat well > known writeup by Venners and Odersky. It's very long so I'll explain > the gist here, but the full paper can be found here: > http://www.artima.com/lejava/articles/equality.html > > What they propose is adding a protected boolean canEquals(Object o) > method. The equals() method will actually call other.canEquals(this), > and if that is false, return false. The standard implementation of any > canEquals method pretty much always looks like: return (o instanceof > Point3D);, where Point3D is replaced with the closest parent (or > yourself) that added equality-significant state. Thus, ArrayList and > LinkedList would not override AbstractList's canEquals (which has: > return (o instanceof AbstractList);), but something like a ColoredList > WOULD override and replace it with "return (o instanceof > ColoredList)". This works.... provided you don't forget to override > the canEquals() method, which, as its certainly not a standard java > idiom is easy to forget, and it also introduces another method to the > API. > > My flash of insight here is to use this trick to entirely avoid the > need for a canEquals method *AND* automatically do the right thing, > leaving virtually no room for accidental error: > > if (!(o instanceof Self)) return false; > Method m1 = o.getClass().getMethod("equals", Object.class); > Method m2 = Self.class.getMethod("equals", Object.class); > if (m1 != m2) return false; > > The idea is: If a hypothetical other.equals(this) call would end up > using the same equals method as myself, then these objects could be > equal, even if their actual types don't match. A new equivalence > relation, like Point3D or colouredlist, HAVE to override equals so > they can include their new property (z for Point3D, colour for > ColouredList) in the comparison. However, an implementation detail, > such as ArrayList and LinkedList, or a JPA proxy, have absolutely no > need for overriding AbstractList/Point's equals method, and in fact, > they don't. I've double-checked the java sources, neither LinkedList > nor ArrayList override AbstractList's default equals implementation. > > I guess there's a somewhat theoretical space where a subclass > overrides equals() for efficiency reasons, but that's probably an > acceptable price to pay to gain the advantage of not having another > method cluttering up the API, and a far smaller chance of breaking the > contract by forgetting to override canEquals. > > Am I missing something, or is this too hacky a solution? > > > FOOTNOTE: Why is equals problematic? > > Equality in java is a lot more problematic than you might at first > glance think. Josh Bloch, when he wrote effective java, proposed the > following template for writing equals methods. Let's assume we have a > simple point class: > > public boolean equals(Object o) { > if (o == null) return false; > if (o == this) return true; > if (!(o instanceof Point)) return false; > if (((Point)o).x != this.x) return false; > if (((Point)o).y != this.y) return false; > return true; > } > > Simple enough. But wrong. In the second edition, the instanceof check > was revised to this: > > if (o.getClass() != this.getClass()) return false; > > and the reason is the equals contract, which says that equality in > java must be reflexive (if a.equals(b), then b.equals(a) must also > hold), symmetric (a.equals(a) must always hold) and transitive (if > a.equals(b), and b.equals(c), then a.equals(c) must hold). symmetric > is simple enough, but the others aren't. Let's say there's a subclass > of Point named 3d point, which adds a z coordinate. > > Equals is easily rewritten to include: if (((Point3D)o).z != this.z) > return false; - but what should Point3D do when you give it a Point > class? There's only one thing to do, because of the reflexive rule: It > should compare x and y and not compare z (as the non-3D point has > none). It HAS to do this - because when calling > point2d.equals(point3d), that's what happens, and you have to do the > same as it. > > But now we're in deep trouble. If [0, 0, 1] is equal to [0, 0], and > [0, 0] is in turn equal to [0, 0, 2], we are forced by the > transitivity rule to conclude that [0, 0, 1] is equal to [0, 0, 2]. > But that's preposterous! Nobody would expect these 2 different points > in 3D space to nevertheless be .equals() to each other. And yet, > that's the ONLY way to get equality right if Point is written with > that instanceof check. > > This is why Josh revised effective java. But now we have a problem: > Technically, one should only use subclassing when changing the nature > of objects. i.e. you have a class named "Shape" and you subclass it to > create "Square". It's perfectly allright than any random shape is > never equal to a square, but unfortunately there's a lot of > subclassing merely for implementation details. For example, LinkedList > and ArrayList are virtual similes of each other and certainly model > the same construct, they are just different implementations. > AbstractList's equals() method is basically broken because a > LinkedList can be equals to an ArrayList - it uses the instanceof > style. As long as you only create implementations which don't add new > state of their own, you're fine, but if you ever create a ColoredList > class, which gives all lists color, you MUST write its equals method > so that an empty red list is equal to an empty blue list, even though > that seems ridiculous. After all, you can't change ArrayList's > equals() method, and it will ignore that color property. Then, by way > of transitivity, red lists equal blue lists if their contents are > equal. Your hands are tied. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.