I think Ari defines a concept that is neboulus to begin with, then he proceeds to show that the definition is troublesome. Go figure :-) That is a cheap parlour trick that no one falls for. However, the discussion about equals and so on is interesting.
Show of hands here, when did you last implement equals, compareTo or hashcode. Did you do it consistently?
I do it sometimes
, not nearly enough as often as I should. But that is probably something we all know. But what I am not sure about is how you do it.
equalsit should be reflexive, symmetric, transitive and consistent for non null values. This is often not a problem, usually there is a String member or something like that you can delegate to and do the same with hashcode. But what I am not sure about is how to handle mutable objects. Should they generally delegate to the default Object equals? I think so.
compareTofollow the same rule of thumb? Do not implement it for mutable objects?
I am not sure, probably. It seems cleaner to implement a comparator for mutable objects and let the comparator handle the dirty stuff if objects mutate during a sort. Most probably the only sane way to deal with that situation is to ignore it :-)
By the way, my friend still has not started a blog.