So I've searched a lot about @Immutable / @Stable ...
# compose
t
So I've searched a lot about @Immutable / @Stable but I have an hard time to understand the cases when it's properly inferred or not. I have data classes that are shared with non compose apps so I'd prefer not to add compose-runtime to those modules. But I do not really understand if it's currently possible to wrap then with no cost or help compose without those annotations.
👍 4
e
I don't know but there's more than just
component#()
with data classes: https://jakewharton.com/public-api-challenges-in-kotlin/
t
Any clue about original question?
a
There was a discussion recently.
t
Thanks I've read that one, wrapping is suggested as only solution but on large list it have a huge cost. That's why I wonder how to properly wrap things without cost if possible. But I suppose it's not possible and probably better to duplicate module or add the runtime dep 😞
a
Well you can't create a new object without any cost but wrapping a list doesn't cost much no matter the size of the list:
Copy code
@Immutable
class ListWrapper<T>(
    val list: List<T>
)
t
The list is part of a larger complex object 😞 Those module are reusable API converters from different servers API to a common internal one via complex moshi adapters and extracted due to kapt. I guess I'll add the runtime dep as I'll probably migrate all to compose in the long future. Does just adding the runtime deps have impacts or risk on the Kotlin version used ? Or I can use older / later kotlin version with just that dep?
a
Only the compose compiler is tied to a specific Kotlin version, but you have to apply compose compiler to your model module so you have to use that version anyway. By the way, you can make compose runtime a
compileOnly
dependency if you don't want it to be pulled in in non-compose modules.
t
Hum ok thanks for the info will see how it goes.