Hi! Two questions: 1. Does `@Stable` imply `@Imm...
# compose
d
Hi! Two questions: 1. Does
@Stable
imply
@Immutable
or vice versa? 2. If I have a
data class
which contains only vals (which are either other data classes or privitives or non-mutable collection types), does it mean that Compose compiler plugin will be able to infer `@Stable`/`@Immutable` automatically? I found an earlier thread that seemed to suggest that. 3. It would be great if both of these points were somehow covered in documentation (or did I miss that?)
2
a
Immutable implies Stable. Stable means that for object instances a and b, the result of a.equals(b) will always return the same result regardless of any changes made to either a or b. In practice this means any change to a is reflected in b and vice versa; they share some sort of internal structure.
Immutable implies Stable because immutable can't change at all, trivially satisfying this contract.
The compose plugin will infer stability if your data class has fields of only other stable types, yes. Primitives and strings are considered stable. Read-only collections such as List<T> are not.
e
What would be an example of something that was stable but not immutable?
a
A type with several
by mutableStateOf
properties. It can change, but it's always equal to itself and notifies compose of those changes when they happen. Similarly, a type that points at the same stable objects and compares as equal if the objects it points to are reference equal
d
I see, thanks! So if my data class has
List<T>
,
Map<T>
or other effectively immutable data structure I should explicitly mark this class as Immutable, otherwise I can rely on compose smartness 🙂
a
yes,
@Stable
and
@Immutable
make a promise to compose that it can't verify without knowing the semantic things you know about your code. You can declare a type
@Immutable
that contains a
List<T>
, but if you assign a
mutableListOf
to that property and start changing it you're going to have a bad time
😂 1
d
Got it! 👍