A modern programming language that makes developers happier.

kotlinlang

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

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. 

<@U0KMMQA20> 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?

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

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

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)

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. 

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