I noticed a lot of “removed `data class` from {lis...

# compose

[Zach Klippenstein (he/him) [MOD]]

I noticed a lot of “removed data class from {list of types}” in alpha11 – what’s the reason for this purge? I know data classes are bad for library binary compatibility, is that it?

[jim]

Yeah, mainly binary compatibility. But there are other small nits that make data classes a little valuable than the syntactic sugar would at first appear, but that is a whole other topic not directly relevant to Compose.

[louiscad]

a little… more, or a little less?

[jim]

It's just small nits, like the fact that the hash code is not memoized, which becomes a perf sink in cases where your data class has all vals which should always be the case anyway or else hashcode is pointless anyway.

[Zach Klippenstein (he/him) [MOD]]

yea, we like to pretend data classes with all-vals are nice value types, but they’re really not

[Daniele B]

Can you please explain this a bit better?
My “*app state*” (which is the data I pass to JetpackCompose) is actually a data class with all vals. I thought this is the best structure to hold data.
What else should be used instead?

[Zach Klippenstein (he/him) [MOD]]

Data classes are just shorthand for writing your own equals, hashcode, toString, and copy methods by hand. The compiler writes all these for you, but the way it implemented hashcode is to calculate it on every call. What Jim is saying is that in some cases, compose calls this method so often that this calculation takes too long.

Data classes are bad for binary compatibility because if you publish a library that includes a data class in its public API, then you add a property to the class and publish a new version, the byte code for calling the old copy method will not be valid for calling the new copy method generated by the compiler because of the new property.

[Zach Klippenstein (he/him) [MOD]]

Jake wrote a blog post about that problem, you can probably just google Jake Wharton data classes

[Daniele B]

@Zach Klippenstein (he/him) [MOD] I guess you are referring to this article:
https://jakewharton.com/public-api-challenges-in-kotlin/

[Daniele B]

It seems it has to do with Java/Kotlin compatibility. But what about for greenfield Kotlin projects?

[Zach Klippenstein (he/him) [MOD]]

Idk if the advice applies to klibs (libraries shipped as IR), but it would to anything that uses Java bytecode

[Daniele B]

What about in terms of the Compose compiler? do data classes really create a significantly bigger burden?

[louiscad]

Compose compiler is no stranger to binary compatibility I guess, other projects might build on top of it.

[Daniele B]

At the end of the article it's written:
"Future versions of Kotlin will stabilize compiler plugins allowing these patterns to be placed behind annotations or custom modifiers."
So does it mean that these issues of data classes could be solved by new Kotlin versions?

[Zach Klippenstein (he/him) [MOD]]

The data class issue has nothing to do with compiler plugins. Data classes have been a feature in the core kotlin compiler since 1.0, and the feature itself is very stable. The issue is that individual data class’ definitions cannot be changed in a way that preserves binary compatibility.