2 ms·
> No, that's not enough. Some collections (such as hash maps and has sets) additionally require that the hashCode does not change over the object's lifetime, or
by wiseowise 4y ago
> No, that's not enough. Some collections (such as hash maps and has sets) additionally require that the hashCode does not change over the object's lifetime, or at least over the time the object is in the collection.
If everything declared val in Kotlin, wouldn't that be enough?
- pron 4y agoSure, just as any immutable object is fine in this regard. But the point is not the fact that we can write some classes that are well-behaved in certain respects, but that we can reify a concept as construct known to provide those guarantees. That's exactly what enums and records do, but data classes don't. You could always code regular classes with behaviour similar to that of enums or records, but the point of enums and records is that all enums and all records are known to have their respective kind of behaviour.