4 ms·
Kotlins data class is functionally basically the same as a lombok @Data class used in Java. Why Java didn't keep the name "Data class" I don't know.
by Number157 6y ago
Kotlins data class is functionally basically the same as a lombok @Data class used in Java. Why Java didn't keep the name "Data class" I don't know.
- ragnese 6y ago"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods. So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is) I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exactly what we've been calling "class whose equals() is defined by content rather than identity" for many years.
- kaba0 6y agoBecause while in the end project valhalla will not call them value classes, it is a sort of an overloaded term. Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.
- ragnese 6y ago> Structs/value types can be mutable, records are not. Fair point about record fields not being reassignable (not the same as immutable for others reading this). > And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference. Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value types. But in light of your first point, I agree that choosing a totally new term probably makes sense.
- kaba0 6y agoI stand corrected, shallowly immutable or as you note fields not being reassignable it is.