so nowerdays expect actual classes are considered experiment

Question

so nowerdays expect actual classes are considered experimental read nawty by kmm I ve got some code where I ve used them extensively to interop a library that has completely different android and ios implementations but what is the prefered pattern here so I can effectively commonise and present these two weirdos as a consistent class

Sebastian Sellmair [JB] · Answer

I would be interested to learn about your code Would be writing a plain old interface in commonMain be sufficient for you

Sebastian Sellmair [JB] · Answer

I tend to like src commonMain kotlin MyInterface kt src appleMain kotlin AppleMyInterface kt

Pete Hellyer · Answer

So the libraries referred to are 3rd party libs that interact with an IoT device both of which are implemented with similar but quirky differences on both iOS and Android I assume two non overlapping dev teams in each of these there is a device class previously I abstracted these classes up to common by using expect actual classes and translating between the natives and kmm but since expect actual classes have been moved back to experimental which makes me wonder if the architecture I m using here Native Class gt Kmm platform specfic expect class gt common class is the wrong approach

rocketraman · Answer

> since expect actual classes have been moved back to experimental What is your source for this < Pete Hellyer> As far as I know they are in Beta status along with Kotlin multiplatform itself

rocketraman · Answer

<https kotlinlang org docs components stability html current stability of kotlin components> Expect actual has been in Beta status since 1 2

Jeff Lockhart · Answer

He probably just means that in Kotlin 1 9 20 the expect actual feature requires a compiler flag opt in Several Kotlin Native features that were implicitly experimental are now explicitly experimental or beta now in Kotlin 1 9 20 too

Jeff Lockhart · Answer

I hope that expect actual isn t being discouraged now While I ve used the interface platform implementation pattern in apps with dependency injection from a library perspective expect actual works better for providing a common KMP API that wraps existing platform implementations <https github com jeffdgr8 kotbase|My database library> makes extensive use of expect actual for example

russhwolf · Answer

Expect classes in particular are not being stabilized at the moment <https youtrack jetbrains com issue KT 61573> But they re staying in beta not experimental

rocketraman · Answer

Yeah I wouldn t take the need for the flag as a hint it is being deprecated discouraged I think that change was just to allow developers to be more rigorous with explicitly choosing to use pre stable features Beta status explicitly means you can use it keeping in mind that there might be some migration work going to stable

rocketraman · Answer

From that issue linked above by < russhwolf> gt We don t plan to drop expect actual classes but as we tweak and refine their design there might be some breaking changes in the future

Jeff Lockhart · Answer

The scope of expect actual specifically for for non final classes did <https youtrack jetbrains com issue KT 22841|narrow in 1 9 20> This required me to abstract non final API classes further and wrap state in an additional final class layer

Pete Hellyer · Answer

yes specifically referring to the decision for expect actual to be experimentalised for classes I supposed my question boils down to what would be stable here my understanding from reading various things including those linked above is that expect actual classes aren t the advised pattern

rocketraman · Answer

This comment from Roman is probably the most relevant <https youtrack jetbrains com issue KT 61573 Emit the compilation warning on expect actual classes The warning must mention that expect actual classes are in Beta focus=Comments 27 8052620 0 0> note here he says experimental but I think he is using it loosely as pre stable rather than formally experimental