Data class' equals() and hashCode() implementation is not calling equals/hashCode of superclass

1

Hello,

I wonder: why default implementation of equals() and hashCode() methods in data classes are not calling superclass’ equals and hashCode?

Taking aside good practices like open-close principle, composition over inheritance, immutability (legacy code still exists):

Right now when data class inherits open or java class with properties, I have have to (either):

  1. override properties of this class - fragile solution as I can easily forget to override new property of subclass when modifying superclass and also there are two different methods of testing equality of same properties - which shouldn’t but can lead to errors
  2. Implement equals and hashCode manually - so I lose one of the benefits of data class

I wonder if it works like this on purpose or it’s something that could be added in future versions of kotlin

2

try to avoid this way
dataclass in kotlin is a kind of java pojo
inheritance is a last resort, when composition impossible
for your needs you have as many interfaces (like categories) as you want and yes you have multiple annoying implementations for each category set
but finally you have abstract api to your data-model and it’s awesome
and your api-user-implementations is under the hood of each api-user-layer, providing own methods including hashcode and equals

3

Thanks for response

I’m aware of this as I mentioned in initial post: “Taking aside good practices like open-close principle, composition over inheritance, immutability (legacy code still exists)”

Unfortunatelly sometimes we have to deal with legacy code and we want to improve it incrementally in very limited amount of time and as I understand beinig able to retrofit it into legacy code is on of goals of kotlin lang project

For some reason kotlin allows to inherit from open/java classes in data classes (if intention was to forbid it than it could be easily blocked on linter and compiler level), so imo it would be nice if default implementation of equals and hashCode would call superclass’ equals and hashCode. At least this is what I would expect as developer and I think it can easily be assumed by other developers (and overlooking it can lead to very serious unexpected behaviors that are not so obvious to detect and debug, e.g. if such object was key in hashmap)

I just wonder what driven this decision (or maybe it was just overlooked, which I wouldn’t expect)

4

legacy

compiler generated inheritance of equals i can understand (but why), and what do you want from hashcode? it just a number
i think manual implementation is the solution, but if you just can - try to pay this technical debt as soon as possible, i made same mistake with legacy, this path is full of pain