https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
j

jw

09/03/2021, 2:15 AM
with hmpp can i define an expect class in commonMain, redefine it as an expect in intermediateMain with more functions, and then actual it in platformMain?
r

russhwolf

09/03/2021, 2:49 AM
I’ve never tried, but you might be able to hack it with a typealias commonMain
Copy code
expect class Foo { ... }
intermediateMain
Copy code
actual typealias Foo = Bar
expect class Bar { ... }
platformMain
Copy code
actual class Bar { ... }
👍 1
j

jw

09/03/2021, 3:02 AM
ahaha oh my god this is horrible
if somehow i could hide
Bar
from public API I would love it
s

Sebastian Sellmair [JB]

09/03/2021, 7:57 AM
@jw This is what we call ‘expect refinement’ and the compiler is not able to do this. The commonizer is special and has a way to refine APIs down the line. This is the first time I see users publicly asking for such a feature for library authors!
@russhwolf Really nice trick, btw 😁
😂 1
j

jw

09/03/2021, 11:25 AM
Oh wow I've had this need for quite some time. I just thought HMPP may have enabled it.
s

Sebastian Sellmair [JB]

09/03/2021, 12:16 PM
No and tbh, there is not even a ticket for this afaik 😕 This indeed was one of the big blocker for commonizing beyond the first level of “common” source sets. Supporting something like it would not be a lot of effort. We never rejected the idea, but given the efforts for HMPP and the current state of that we think it’s not on the top of the queue 😕
r

russhwolf

09/03/2021, 3:08 PM
If you're ok with another layer of workaround, you could try an opt-in annotation to keep
Bar
out of public API.
Copy code
@RequiresOptIn
annotation class InternalApi

@OptIn(InternalApi::class)
actual typealias Foo = Bar

@InternalApi
expect class Bar
But it might not be viable for you because then the new members of
Bar
are also not public API.
l

louiscad

09/03/2021, 3:10 PM
That annotation can also be made internal to fully prevent opt-in outside the module.
j

jw

09/03/2021, 3:13 PM
Yeah I need them to be public API, unfortunately. I have some workarounds in place by using interfaces which are themselves expect/actual to mix-in the new API but that also creates new public types. At least they're supertypes, though, and not subtypes, so you remain mostly blissfully ignorant of their presence.
r

russhwolf

09/03/2021, 3:15 PM
Oh yeah that's a good trick too
7 Views