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

natpryce

03/13/2018, 6:46 PM
If any JetBrains dev’s are reading… I already have this building for both JVM and JS platforms without using the language mechanisms for multiplatform. The multiplatform language features and build conventions make it require much more work than necessary.
m

marcinmoskala

03/14/2018, 7:17 AM
Any details?
n

natpryce

03/14/2018, 7:17 AM
I’ve been thinking about why overnight…
I think it’s because the multiplatform support adds additional constraints beyond those already provided by the type system
But those constraints don’t add any more safety than would already be provided by the type system.
My multiplatform project precedes the multiplatform language features. For each platform, I compiled the cross-platform and platform-specific code as a single compilation unit, and the type checker caught any platform differences that affected my code.
But to meet the additional (and unnecessary) constraints imposed by the multiplatform language mechanisms, I have to write lots of boilerplate code and duplicate code in my platform-specific modules.
The huge increase in effort is not worth the benefit (slightly better navigation in IntelliJ)
If IntelliJ could work well with the same source directory being used by multiple modules, then multiplatform projects would require no new language features.
And much less work from the programmer
m

marcinmoskala

03/14/2018, 11:02 AM
I am not a developing it, but I believe that some example will be really helpful for Kotlin team
n

natpryce

03/14/2018, 11:02 AM
The issues I’ve raised in this channel w.r.t. using the DOM APIs are an example
m

marcinmoskala

03/14/2018, 11:03 AM
I mean some actual code
n

natpryce

03/14/2018, 11:03 AM
The DOM APIs are source compatible between platforms. I can compile the same code for both JS and JVM, but only if I don’t use the language features for multiplatform
As soon as I do, I have to write
expect
declarations for all of the DOM APIs I use.
But I can’t because they are interfaces on JVM and external classes on JS
so I have to write my own
expect
types in the common module and identical
actual
implementations for JS and JVM platforms
And at that point it was obviously too much work for too little benefit.
There is no code using the multiplatform language features.
only the original multiplatform code not using those language features exists
i

ilya.gorbunov

03/14/2018, 2:41 PM
If IntelliJ could work well with the same source directory being used by multiple modules, then multiplatform projects would require no new language features.
Yeah, if that was true we wouldn't have to invent all these expects and actuals.
The main problem in that approach is that the same common code must be analyzed in multiple contexts, one at a time for each platform. Not only this is technically challenging, it's also unclear how to provide a reasonable IDE experience, when every bit of API you call is some quantum superposition of all available platforms.
n

natpryce

03/15/2018, 9:16 AM
IntelliJ already annotates lines of code with the results of multiple inspections, and the user experience is fine
But if that isn’t a good approach, could something be done to make the expect/actual mechanism more convenient -- require less boilerplate and duplicated code?
For example, in my code I don’t care if a platform type (W3C DOM types in my case) is provided by a class or an interface, because I only call methods, and don’t subclass or implement platform types.
If there was a way to
expect
a type without constraining its definition to be a class or interface, then I’d not have to write lots of wrapper types and boilerplate to forward to identical APIs on each platform — I could just use
actual typedef
.
I’d still have to declare all the
expect
types and
actual typedef
declarations, which is tedious, but maybe I could write an IDL generator for that.
6 Views