Thread
#compose
    d

    dimsuz

    1 year ago
    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
    ?
    j

    jw

    1 year ago
    Generally, you should never put a
    data class
    into the public API of a library.
    The generated functionality makes it nearly impossible to compatibly migrate it to contain additional properties.
    Bryan Herbst

    Bryan Herbst

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

    dimsuz

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

    jw

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

    Andrew Neal

    1 year ago
    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
    d

    dimsuz

    1 year ago
    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

    Colton Idle

    1 year ago
    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?
    j

    jw

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