|
|
|
|
|
|
by nicolai-parlog
1873 days ago
|
|
|
That misses the point. The strength of records is that the language can build features that are only possible because of records' restrictions. It's not that the bytecode says "I'm a record" - which is all you get if Kotlin compiles a data class to one. @JvmRecord gives you all the limitations with none of the benefits. The annotation only exists for compatibility reasons. |
|
|
The only benefits I've seen in your article are not available right now, and can (and sometimes are) matched by Kotlin and even Lombok.
* Destructuring pattern matching syntax (JEP 405)
Proper pattern matching is obviously one of Kotlin's weak spots, but nothing prevents it from developing this in the future. Just like Java has JEP 405, Kotlin has KT-186[1], although Java might (uncharacteristically) beat Kotlin to this one.
* with blocks
This solution is far away and relies on introducing new syntax to the language. Meanwhile both Kotlin and Lombok already have solutions that give you the same benefits without introducing new syntax.
Lombok has both @With and @ToBuilder, while Kotlin has the copy() method.
* Serialization
As far as I can see, Kotlin Serialization already supports algebraic data types - including Sum Types, not just Product Types!
* Boilerplate reduction
I don't think you were trying to imply otherwise, but just to be clear about it, this is the benefit that both Kotlin and Lombok data classes had from day one.
[1] https://youtrack.jetbrains.com/issue/KT-186