tag:blogger.com,1999:blog-3083788237966827171.post8302673659080073093..comments2023-11-03T04:16:02.546-07:00Comments on Jesper's Blog: Equality, Mutability and ProductsJesper Nordenberghttp://www.blogger.com/profile/07589508061874776093noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3083788237966827171.post-1406527599823192512009-06-18T15:15:26.700-07:002009-06-18T15:15:26.700-07:00Sorry for the late replies, I need to check for co...Sorry for the late replies, I need to check for comments more often :)<br /><br />@chris: I'm not assuming all implementations of equals() are time invariant, in fact I gave an example in the post on where it wasn't. My point is that implementations should be time invariant though as many usages of equals() (even in the JRE) assumes it is. Your project looks interesting and similar to what is generated by the Scala compiler for case classes, except there you can't mark which fields should be included/excluded in the generated code. Btw, can't seem to find the scala-user discussion either...<br /><br />@morgan: Yes, defaults matters. :)Jesper Nordenberghttps://www.blogger.com/profile/07589508061874776093noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-6143703442201141222009-05-31T21:09:54.563-07:002009-05-31T21:09:54.563-07:00Thanks for the interesting post.
So, in Java, you...Thanks for the interesting post.<br /><br />So, in Java, you get the base equals and hashCode behavior, unless you override them. But in Scala case classes, you get a field by field equals and hashCode behavior, unless you override them (or extend your Mutable trait).<br /><br />Somehow this difference reminds me of how Java and C++ treat virtual functions differently. In C++, functions have to be marked virtual by the special keyword. But in Java, functions are virtual <I>unless</I> they are marked by a special keyword (final).<br /><br />It's interesting to me how changing "defaults" from one language to another can reflect profound philosophical differences.Morgan Creightonhttps://www.blogger.com/profile/10229228897201330840noreply@blogger.comtag:blogger.com,1999:blog-3083788237966827171.post-63540976168134162352009-05-03T02:51:00.000-07:002009-05-03T02:51:00.000-07:00Good post, however I was a bit confused upon initi...Good post, however I was a bit confused upon initial reading and I thought you were asserting that time-invariance was a requirement of Object.equals(). I was even preparing to correct that assumption when I realized that was probably not your intent. For the sake of clarity, you might consider changing "There are many different types of equality" to something like "There are many different ways to implement equality". Also, a link to the archived scala-user discussion (e.g. <A HREF="http://www.nabble.com/Scala---User-f30217.html" REL="nofollow">Nabble</A>) would have been nice, as I was unable to find it.<br /><br />On a related side-note, I would like to point out a project I've been working on which aims to provide correct, low-maintenance implementations of hashCode() and equals() (as well as a resonable implementation of toString()) by using Java annotations to mark fields or methods for use in any valid combination of those operations. It prevents you from doing things like including a value in hashCode() which is not a part of equals(), for example. The project is called <A HREF="http://www.pojomatic.org" REL="nofollow">Pojomatic</A> and can be found on SourceForge if you are interested. It was written with Java conventions in mind (e.g. getters and setters) but I can't think of a reason why it wouldn't work well in Scala.Anonymoushttps://www.blogger.com/profile/09718897309693652777noreply@blogger.com