Beware of the destructuring behaviour in Kotlinâs data classes
⌠2023-01-25
Donât get me wrong, Kotlinâs Data classes are super cool. If youâre not using them already, you really should be. With data classes you get:
- Automatic implementation of
equals
andhashCode
, - A workable
toString
function, - A cool
copy
method for duplicating objects and updating its properties, and - Destructuring syntax through
compotentN
function generation.
Itâs that last point, about the destructuring syntax, that Iâm a bit weary of. If youâre not already familiar, hereâs how destructuring works for Kotlin data classes:
val lientjie = Cat("Lientjie", 2016)
val (name, yearOfBirth) = lientjie
println("$name, born in $yearOfBirth")
// prints "Lientjie, born in 2016"
The order that the data classâs constructor parameters are defined is the order that those compotentN
functions are generated.
What this means is that you canât add a new constructor parameter to a data class unless either:
- The new parameter is inserted last in the list, or
- Youâre very sure that no code depends on the classâs destructuring order
For example, if we were to extend the Cat
class so that it accepted numberOfVaccinations
as the second parameter, weâd introduce a subtle bug. All without a compiler warning.
val lientjie = Cat("Lientjie", 8, 2016)
val (name, yearOfBirth) = lientjie
println("$name, born in $yearOfBirth")
// prints "Lientjie, born in 8" <- eek
I donât think its a deal-breaker, especially for data classes that donât leak into your codeâs public contract, but certainly something to keep in mind.