I've a fundamental question about `expect/actual` ...
# multiplatform
c
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
?
đźš« 4
r
common
code can only access other
common
code
if you create
expect
function or class in
common
you can access it, even though the
actual
code will be defined elsewhere
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
c
Okay so the only way for
common
code to access anything else is if it is declared in common using the
expect
keyword?
Okay understood. Thanks!
r
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.
c
@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
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,
r
For example, interfaces can't define constructors
But depending on how you structure your code they usually don't need to.
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.
👍 1
k
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.
👍 2
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
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