If any JetBrains dev’s are reading… I already have...

# multiplatform

[natpryce]

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.

[marcinmoskala]

Any details?

[natpryce]

I’ve been thinking about why overnight…

[natpryce]

I think it’s because the multiplatform support adds additional constraints beyond those already provided by the type system

[natpryce]

But those constraints don’t add any more safety than would already be provided by the type system.

[natpryce]

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.

[natpryce]

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.

[natpryce]

The huge increase in effort is not worth the benefit (slightly better navigation in IntelliJ)

[natpryce]

If IntelliJ could work well with the same source directory being used by multiple modules, then multiplatform projects would require no new language features.

[natpryce]

And much less work from the programmer

[marcinmoskala]

I am not a developing it, but I believe that some example will be really helpful for Kotlin team

[natpryce]

The issues I’ve raised in this channel w.r.t. using the DOM APIs are an example

[marcinmoskala]

I mean some actual code

[natpryce]

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

[natpryce]

As soon as I do, I have to write expect declarations for all of the DOM APIs I use.

[natpryce]

But I can’t because they are interfaces on JVM and external classes on JS

[natpryce]

so I have to write my own expect types in the common module and identical actual implementations for JS and JVM platforms

[natpryce]

And at that point it was obviously too much work for too little benefit.

[natpryce]

The project is here: https://github.com/npryce/snodge

[natpryce]

There is no code using the multiplatform language features.

[natpryce]

only the original multiplatform code not using those language features exists

[ilya.gorbunov]

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.

[ilya.gorbunov]

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.

[natpryce]

IntelliJ already annotates lines of code with the results of multiple inspections, and the user experience is fine

[natpryce]

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?

[natpryce]

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.

[natpryce]

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.

[natpryce]

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.