When I have an immutable class, which I have not i...
# compose
s
When I have an immutable class, which I have not implemented
.equals
and
.hashcode
for, and it is also not a
data class
. And it only contains parameter types that are considered stable by default. And this is compiled in a module which does have the compose compiler applied in. Say like this:
Copy code
class SomeContainer(
  val input: String,
  val otherInput: Int,
)
Will composables that use this as a parameter be able to be skipped properly? • Does the compiler still mark this as @Immutable even though I am not implementing the equals/hashcode functions? • Will this be considered unstable but will still be able to be skipped if strong skipping mode is turned on since it will then do
===
on it? • Something else? I tried to scour through the documentation for this but I can't say I've found the right place where this scenario is explained.
s
I don't think compose special cases data classes, so the same rules apply here From my intuition, it will mark this class as stable and generate runtime checks in other module to skip if the class from the dependency is still stable
The other issue is that
.equals
is not implemented, so the only check you'll get is reference equality
s
So if it's marked as Stable, it will try to do
.equals()
on it, but since I am not implementing that, it will fall back to doing a
===
and in the end the result will be that I still get proper skips, despite me making the mistake of not implementing equals. Is my understanding here correct? I mean of course it's still a good idea to just make it a data class to get that for free, but I was wondering what happens if someone just makes a mistake and forgets about it.
s
Yeah, assuming the same instance is passed to the function, it will skip
s
Because if someone makes a new instance of this object, even if the
input
and
otherInput
happen to be the exact same values, the referential check will fail and then it will not skip, right?
s
Yep, exactly
s
Perfect, I think that clears my questions! Thanks a lot Andrei!