The mapping of the W3C DOM IDL to Kotlin is different on JVM and JS platforms. On JVM, the DOM int...

# multiplatform

[natpryce]

The mapping of the W3C DOM IDL to Kotlin is different on JVM and JS platforms. On JVM, the DOM interfaces are mapped to Kotlin interfaces. On the JS platform, the DOM interfaces are mapped to Kotlin classes. Is this a defect?

[Big Chungus]

It's not. On jdk they're defined as interfaces whereas in the browser they are classes (since js doesn't have interfaces)

[natpryce]

JS doesn’t really have classes in the Kotlin sense either.

[Big Chungus]

True, it's all functions in a trench coat

[natpryce]

I should be able to write a Kotlin class that implements a W3C DOM interface and other interfaces, but that’s not possible in the existing mapping. Which I consider to be a bug in the mapping of IDL to Kotlin on the JS platform.

[natpryce]

(It also makes writing multiplatform code that uses the W3C DOM impossible)

[Big Chungus]

You still can, just don't use dom classes from stdlib and declare them as external interfaces yourself

[natpryce]

Not ideal… that’s a lot of busywork to re-declare types that are already declared. Is it possible to declare external interfaces that have the same fully qualified name as a type in the stdlib?

[Big Chungus]

Kinda, but it's hacky. You basically suppress expect with no actual errors in common code and actual with no expect in platform code. But doing so removes all compile-time guarantees

[natpryce]

And requires re-declaring the entire DOM API by hand.

[Big Chungus]

https://github.com/JetBrains/kotlin/blob/master/compiler/frontend/src/org/jetbrains/kotlin/diagnostics/rendering/DefaultErrorMessages.java#L95

[Big Chungus]

And requires re-declaring the entire DOM API by hand.

No, you can still typealias

[natpryce]

But wouldn’t I need to declare the interface methods in the expect declarations?

[Big Chungus]

Correct

[natpryce]

That’s what I mean by redeclaring the DOM API

[Big Chungus]

But you'd need to do that for any kmp code that relies on platform APIs

[natpryce]

Except that the APIs should be exactly the same on JS and JVM – generated from the IDL published by W3C and in the stdlib on both JVM and JS platforms.

[natpryce]

The only difference is that Kotlin JS declares them as classes and the JVM declares them as interfaces.

[natpryce]

But apart from that keyword, they have the same methods.

[Big Chungus]

Tell that to JDK API folks 😀

[Big Chungus]

And they can't be identical anyways. How do you propose registering event handlers on jvm?

[natpryce]

Interfaces is exactly what they are though. You cannot instantiate them. Even on JS, you have to ask the DOM implementation to create instances.

[natpryce]

That’s DOM level 1 v level 2. I think having different DOM levels on each platform is fine. But declaring the mapping of, say, the same DOM level 1 API to be different declarations feels wrong, and makes writing multiplatform code impossible (at least, with the Kotlin multiplatform language feature. It’s possible with old-skool C techniques for writing multiplatform code)

[natpryce]

Anyway… gotta go. I’ll have a think…