Skip to main content
added 435 characters in body
Source Link
talex
  • 159
  • 1
  • 5

I suggest make equal relation completely separate concept. Original method have unavoidable problem: unclear semantics. What does it mean to compare object to another? It is impossible to answer this question in general. Because of that you can always be surprised by results.

And since semantic is unclear chances to be surprised increases if you work with third party code. One popular library wasn't unable to provide symmetric implementation (I'm looking at you appache.commons.lang).

Instead of equals(Object) method use static method boolean equals(TypeFoo, TypeFoo) for each type you want to compare.

If you have TypeBar inherited from TypeBar you just get another method.

If you have some algorithm that requires checking equality relation just parametrize it with interface EqualityRelation<T>{ boolean equal(T, T);} and pass relation you want to use.

No surprises here. You always explicitly tell which relation you want. You can have as many relation between same type as you want. Want to use color and x coordinate of your ColoredPoint? No problem: just define new relation, it is just a method.

I suggest make equal relation completely separate concept.

Instead of equals(Object) method use static method boolean equals(TypeFoo, TypeFoo) for each type you want to compare.

If you have TypeBar inherited from TypeBar you just get another method.

If you have some algorithm that requires checking equality relation just parametrize it with interface EqualityRelation<T>{ boolean equal(T, T);} and pass relation you want to use.

No surprises here. You always explicitly tell which relation you want. You can have as many relation between same type as you want. Want to use color and x coordinate of your ColoredPoint? No problem: just define new relation, it is just a method.

I suggest make equal relation completely separate concept. Original method have unavoidable problem: unclear semantics. What does it mean to compare object to another? It is impossible to answer this question in general. Because of that you can always be surprised by results.

And since semantic is unclear chances to be surprised increases if you work with third party code. One popular library wasn't unable to provide symmetric implementation (I'm looking at you appache.commons.lang).

Instead of equals(Object) method use static method boolean equals(TypeFoo, TypeFoo) for each type you want to compare.

If you have TypeBar inherited from TypeBar you just get another method.

If you have some algorithm that requires checking equality relation just parametrize it with interface EqualityRelation<T>{ boolean equal(T, T);} and pass relation you want to use.

No surprises here. You always explicitly tell which relation you want. You can have as many relation between same type as you want. Want to use color and x coordinate of your ColoredPoint? No problem: just define new relation, it is just a method.

Source Link
talex
  • 159
  • 1
  • 5

I suggest make equal relation completely separate concept.

Instead of equals(Object) method use static method boolean equals(TypeFoo, TypeFoo) for each type you want to compare.

If you have TypeBar inherited from TypeBar you just get another method.

If you have some algorithm that requires checking equality relation just parametrize it with interface EqualityRelation<T>{ boolean equal(T, T);} and pass relation you want to use.

No surprises here. You always explicitly tell which relation you want. You can have as many relation between same type as you want. Want to use color and x coordinate of your ColoredPoint? No problem: just define new relation, it is just a method.