when you compile another common library A that has...

# multiplatform

[agrosner]

when you compile another common library A that has expects and B is a common module that depends on A, do those expects carry over from A and can you partially implement those expects in B?

[ilya.gorbunov]

No, a common module can not have actual implementations for expects in another common module.

[agrosner]

is this a limitation you expect continuing? is it just implementation complexity or is it not something you considered as a feature

[agrosner]

I guess I mean is that its not possible to have a library that is both a multiplatform expect and actual in both unless I make it a source set of both platform modules that share the actuals

[ilya.gorbunov]

We had considered this feature, but it's too complex to implement with the current compiler. We're waiting for some major compiler refactorings to complete to approach this problem again.

[agrosner]

ok sounds good. for now the solution of including it as source set to both android + java project works like a charm.

[gildor]

Why not just provide different implementation for Android and JVM using standard JVM ways: interfaces, inheritance and delegation
I mean it of course seams easier to allow MPP just replace implementation, but it doesn’t seams as bad approach to just implement all expect declarations in JVM module and then use this module as dependency for platform specific module
This approached used for any other JVM library when you want to provide platform specific things

[agrosner]

I want to have expects on things that are not just JVM specific. i.e. it can be implemented by Kotlin native

[gildor]

but for K/N you need different implementation, If you have common one, just keep in comon module

[gildor]

I’m talking about your original case, when you have partial implemenation and want to provide specific one for JVM and Android

[gildor]

but I agree, that structure described by you in message on top of this thread make sense, of course

[agrosner]

ive done a lot of that. IMHO its mostly just add Class lookup methods for java consumers b/c KClass != Class as well I cannot use JvmStatic in abstract classes that are implemented by object