4 ms·
All you're saying is that records are more limited than data classes. You see that as a strength, I see it as a restriction because sometimes, I do like the ex
by hota_mazi 4y ago
All you're saying is that records are more limited than data classes.
You see that as a strength, I see it as a restriction because sometimes, I do like the extra flexibility of adding mutable state to my value objects.
And I know better than altering the value of hashcode after creation, although this only matters if you've put these objects in a hashing container, so it's not even a universal risk.
- setr 4y agoEnums are also more limited than classes, yet they have purpose/place. In fact, that’s the general purpose of types — to reduce capabilities to gain access to guaranteed capabilities, which lets you reach compiler-verified logic rather than simply programmer-verified / unit-test-verified logic. Of course, it only matters if something utilities those guarantees, which I don’t know for kotlin, but C# uses records to expand out the LINQ interface quite substantially/conveniently for value comparison (mainly made convenient when you also have anonymous records)
- pron 4y agoI'm saying that records are a semantic features, while data classes are not. In the context of records, "the extra flexibility of adding mutable state" makes as much sense as saying that sometimes I like the flexibility of adding new instances to my enum classes on the fly. An enum is an enum to guarantee a fixed set of instances in the type. That records and enums are more constrained in their behaviour than ordinary classes is the reason for their existence, because they don't do anything an object of a regular class can't do. Data classes, on the other hand, exist for syntactic brevity. The difference between the features is not a difference in degree but a difference in kind.