I noticed that `Typograhpy` class is now not a `data class` (it used to be), but has the same semant...

# compose

[dimsuz]

I noticed that Typograhpy class is now not a data class (it used to be), but has the same semantics. Why is this so? If I'm making my own Typography-like class why shouldn't I use data class?

[jw]

Generally, you should never put a data class into the public API of a library.

[jw]

The generated functionality makes it nearly impossible to compatibly migrate it to contain additional properties.

[Bryan Herbst]

Jake beat me to it, but I was going to link to his blog post anyway: https://jakewharton.com/public-api-challenges-in-kotlin/

[dimsuz]

oh. As an aspiring library author I should make note of this. And read the article. Thanks!

[jw]

Apparently there's a compiler plugin called "poko" which will give you the value semantics without adding additional public API surface

[Andrew Neal]

FWIW binary compatibility is the reason Typography and others are no longer data classes. There wasn't some other reason those changes were made. https://android-review.googlesource.com/c/platform/frameworks/support/+/1547978

[dimsuz]

Thanks! I'll check out that plugin.
Also I understood that as a consumer, I can use data class for my copy and simplify this a bit.

[Colton Idle]

Hm. I have an additional gradle module that I treat as a library, but it's not consumed by any other teams or anything. It's just for us internally to have some separation and compile time improvements. I suppose in this case, using a data class isn't the biggest deal?

[jw]

No. Externally published libraries where binary compatibility is a concern only.