So solution for shared code is manual Interface/Implementation?


#1

From kotlin native announcement it looks like solution for shared code is “introduce manual interfaces for all platform specific code and manually implementent them + factories + DI”?
Will there be “force inline” to make this heavy GoF way somewhat performant?

edit: if kotlin team insists so heavily on not having macro/conditional compilation I would propose using GWT.create /replace-if like solution for platform classes in common code. At least it automates factories.


#2

Definitely not. Did you get that impression by reading a passage about common modules?

Common modules are more like headers in C++, they can provide declarations without implementations and those implementations are supplied by the platform modules for that common module.


#3

So how it looks like? In C you have separate compile/link steps in build. Will kotlin introduce link step?

.NET Standard works kind of this way. While compiling it links to interfaces, and at runtime rebases to specific runtime implementation via some magic. Will you provide magic runtime linker?


#4

In general it would look like:

common sources + JVM platform sources => :alembic: compile to JVM :alembic: => JVM binary :tada:

A common module by itself does not produce any executable binaries, so there is no linking step required.


#5

Much fanfare but not enough minerals :smiley:
This way it looks like binary libs artifacts are not possible and lib user have to recompile sources. What target artifact is? For java the only option is only jar, but for say native it is .h + .o ?
What physical representation does common module sources have? maven/gradle project or special *.ktHPP files? I know you have *.kjsm files which look like headers.

Is there ETA for docs for module? Otherwise this topic start to look like FAQ :slight_smile:


#6

No it isn’t like that. A multiplatform library consists of a common module and a number of platform-specific modules (one for each platform). A platform-specific module is compiled from common sources and it’s own sources and produces a binary artifact for that platform.
Common module by itself also produces some artifact, but it doesn’t contain any binary executable code.

All these artifacts constitute the compiled library.

I believe there will be nothing special here, native target will produce the same artifacts as it produces now.

These are plain .kt files. You can take a look at the project layout here: https://github.com/JetBrains/kotlin/tree/master/libraries/kotlin.test. Currently we develop that library as a multiplatform project.


#7

So you can declare interface marking funs with ‘header’ keyword and platform specific implementations with ‘impl’ keyword. At least in gradle case they have to be in separate projects. kotlin gradle plugin declares some additional configurations lile ‘implements’ to manage this dependencies.

Looking at kotlin.test there is single fun using this feature. How classes/interfaces and typedefs are fitted into this model? Can i have ‘impl’ interface/class with extra platform specific methods? Platform specific overrides on fun return types/arguments?


#8

I’m currently doing this through gradle, but there is one annoyance, various compile time annotations are only present in the respective platform library (eg @JvmName, @Exception, and @SuppressWarnings. I manually filter them out in the javascript copy, but it would be better if they were just handled by the compiler (by ignoring them when not relevant).