With `@JvmInline value class`es existing, I’ve bee...
# getting-started
s
With `@JvmInline value class`es existing, I’ve been wondering, is there any reason why you would explicitly not want any class you have that happens to have a single value in it’s constructor to be a
value class
? Like I see the benefits of it, but if I am creating a new data class with 1 parameter anyway, why would I not just make it a value class? Any gotchas? Couldn’t find anything in the KEEP regarding this.
s
hmm 🤔, with `data class`es, you get additional helper methods like a
copy()
-method and
componentN()
for destructuring, so you wouldn't get those one your
@JvmInline value class
. But it's not like those seem super valuable if a class only has a single member. But if you start-off with a single member and then decide that it makes sense to add another member, you'd have a bigger PR because now you'd be switching to those convinience methods throughout your codebase!? It's a bit contrived but it's the best i can come up with.
e
value class means you no longer have object identity, and JvmInline results in methods that can't be called from Java (without extra annotations), not to mention problems with kapt due to name mangling. maybe those are ok for your use case, but it's different enough from the behavior of other declarations that it shouldn't be the default IMO
s
Let’s say the project contains no Java anyway. And yeah as you said copy or componentN doesn’t even matter in a single member class. And let’s also assume this class wouldn’t change anyway, it’d always have 1 member. Also could you care to elaborate on what problems arise with Kapt? Any bug reports on YouTrack-GitHub I could look into? I don’t see too many strong arguments against it as of now. I think in most cases none of these matter. I think I will just avoid doing it anyway unless there’s a good reason to actively do it. But I’d still love to hear more arguments so I can make a better informed decision.
d
Json converter libs don't all support them currently afaik...
e
anything using Java reflection (or just the java source model like kapt) will not be able to see inline classes. json through kotlinx.serialization should mostly work though