so nowerdays expect/actual classes are considered ...

# multiplatform

[Pete Hellyer]

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]]

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]]

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

[Pete Hellyer]

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 -> Kmm platform specfic expect class -> common class, is the wrong approach.

[rocketraman]

> 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]

https://kotlinlang.org/docs/components-stability.html#current-stability-of-kotlin-components

Expect/actual has been in Beta status since 1.2

[Jeff Lockhart]

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]

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. My database library makes extensive use of expect/actual, for example.

[russhwolf]

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]

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]

From that issue linked above by @russhwolf :

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]

The scope of expect/actual, specifically for for non-final classes, did 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]

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]

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.