I've a fundamental question about `expect/actual` . Is Kotlin code in `commonMain` supposed to be ab...

# multiplatform

[curioustechizen]

I've a fundamental question about expect/actual . Is Kotlin code in commonMain supposed to be able to access code in iosMain or androidMain even without using the expect/actual mechanism?

So, if I have different implementations of fun getPlatformName(): String each in iosMain and androidMain , but I don't declare expect fun getPlatformName(): String in commonMain am I still supposed to be able to call this function from commonMain ?

[Robert Jaros]

common code can only access other common code

[Robert Jaros]

if you create expect function or class in common you can access it, even though the actual code will be defined elsewhere

[Robert Jaros]

your common code will be eventually integrated into a platform code (ios, android, jvm), but you can't access any platform code directly from common

[curioustechizen]

Okay so the only way for common code to access anything else is if it is declared in common using the expect keyword?

[curioustechizen]

Okay understood. Thanks!

[russhwolf]

You don't have to use expect though it's usually the quickest way to inject platform code into common. You can also define interfaces or lambda parameters in your common code and have your platform code implement them.

[curioustechizen]

@russhwolf This was why I asked this question in the first place 🙂

It looks like expect is not strictly needed. I kept coming up with situations where the interface approach does not work and my team-mate kept proving that I'm wrong.

So basically anything you can achieve with expect you can also achieve with interfaces. Of course it is true that one might be more convenient than the other depending on the situation

[curioustechizen]

The kotlin docs have this statement:

Also, it requires common declarations to be expressed as interfaces, which doesn't cover all possible cases.

I'm wondering what are the possible cases that are not covered by interfaces,

[russhwolf]

For example, interfaces can't define constructors

[russhwolf]

But depending on how you structure your code they usually don't need to.

[russhwolf]

I think I have a similar mindset to your teammate in that I tend to have only small amounts of expect in my code. One of the limitations of expect that I've run into is that you can't swap in other implementations very easily (eg for testing). So I almost never do expect class and tend to limit it to top-level functions and values when I do use it.

[kpgalligan]

I don’t think there will be much expect/actual in app code as the library ecosystem matures. Because expect/actual is a new thing, the “getting started” docs tend to talk about it right away, and people tend to use it a lot when they start. We did the same thing. Had a ton of expect/actual for the first few months, then wound up pulling most of it out in the following months.

[kpgalligan]

Where expect/actual can be useful is in wrapping sdks that have some deeper object graphs. We wrapped Firestore, which has a lot of nested layered calls and data object replies. Doing that with interfaces would mean a lot of wrapping and delegate management: https://vimeo.com/371460823

[kpgalligan]

Basically, they’re useful, but you should fight the urge to use them a lot, and I think “getting started” docs should push expect/actual lower in the priority of things to learn