Are client libraries of Compose expected to declare their own implementors of `Composition` if neces...

# compose

[min]

Are client libraries of Compose expected to declare their own implementors of Composition if necessary? Or is CompositionImpl the only class that matters?

[Zach Klippenstein (he/him) [MOD]]

No, nobody should implement Composition. There’s no reason to, and doing so would be very complex and hard to do as efficiently as compose itself.

[min]

@Zach Klippenstein (he/him) [MOD] Then why is it a public interface? Change of plans? (Originally third party implementations were going to be allowed?) Just a design philosophy? Or to leave the door open for supporting third party types in the future? What’s the point of making a function accept a Composition not a CompositionImpl if every implementor of the interface is necessarily that specific class always?

[Zach Klippenstein (he/him) [MOD]]

I think it was probably an interface to separate the api from impl, not to make it externally implementable. But idk for sure

[Zach Klippenstein (he/him) [MOD]]

Don’t need to tag people who replied to a thread, they already get notified

[min]

Oh I didn’t know that, thanks for letting me know. And separate the API from the implementation… So like an OCaml module and a signature, maybe. Still not sure exactly what for but thanks for sharing your insight, I appreciate it (and your blog post on snapshots! That was brilliant)

[Zach Klippenstein (he/him) [MOD]]

Yea, basically. Or like a header file in C. Pretty common pattern in Kotlin (see also the StateFlow interface, whose docs explicitly say they’re not meant to be externally implementable). Sometimes the interface is made sealed to enforce this, and idk why Composition wasn’t made sealed - probably an oversight.

[min]

Right, it would have made more sense if it were sealed. Either way it makes more sense now, thanks for the explanation