"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Basically, the difference between Odersky's approach and mine is that mine always bubbles up to the top level, whereas his eliminates current class or type differences immediately, so I suspect mine will be slower.
Mike Simmons wrote:The only other improvement I came up with is that canEqual() might as well be protected. There's no need for anyone outside the hierarchy to ever call it. This keeps the API cleaner for clients to understand.
I don't think there's any reason to assume that differences in subclass fields are more important than differences in superclass fields. Depends on the domain I guess - but I see no reason to think this method will be slower in general.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Mike Simmons wrote:Oh, and Winston: please be forthright when crossposting to other sites. [link]
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Chan Ag wrote:Thank you, Winston and Mike for sharing your knowledge with us.
As for me, I will try to use these guidelines when I'm working on similar stuff. Perhaps there is a lot more to know...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:That simplicity comes at some loss of "objectivity", but you should probably ask yourself if you really need it.
Martin Vajsar wrote:That's what I wanted to ask you. So here I go - in how many cases did you need something like this?
I've mucked about with equals a few times and always got burned. In my opinion, anything but the getClass() technique strongly violates the KISS principle.
Having equals bad is horrible mostly because it manifests itself in some code far, far away from the original sin (HashSet cannot be buggy! It must be something else - someone removed that object from my set...), and secondly (this might actually be just my own disposition), you don't expect equals to be wrong - equals is such a stupid simple method!
(I've once spent several hours discovering my compareTo was not transitive. I've even resorted to debug the internals of TreeSet. I'm not going to forget for some time.)
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Martin Vajsar wrote:Having equals bad is horrible mostly because it manifests itself in some code far, far away from the original sin (HashSet cannot be buggy! It must be something else - someone removed that object from my set...)
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
I've mucked about with equals a few times and always got burned. In my opinion, anything but the getClass() technique strongly violates the KISS principle.
And here's where we disagree. KISS is great - I'm a huge believer in keeping things simple - but it MUST be correct.
Winston Gutkowski wrote:Or that your object violates another principle (which I've so far only seen mentioned in Martin Odersky's article) - Defining equals() in terms of mutable fields.
Martin Vajsar wrote:I was actually trying to express a slightly bit different idea - that equality among different classes is inherently not simple.
It's not overwhelmingly difficult, but there are a few points that one has always to keep in mind, and - especially when returning to an old code to make just a small modification, it is really easy to forgot about some of them (for me, it's mostly transitivity).
The canEqual concept is great - and surprisingly simple to understand or visualize, since it allows to define boundaries in the class hierarchy that cannot be surpassed by equality. The problem is that it is not well known. The next Java developer won't learn about it from javadoc or Java tutorials, and when he finds it in the code, he might misunderstand it (why the heck have two methods - equals and canEqual? Can't I do with just one of them?). If canEqual would be included in Java 8 or 9, well, that would be great. The alternative is to have all developers read this discussion.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here