5 ms·
Multiplatform docs here: https://kotlinlang.org/docs/reference/multiplatform.html https://kotlinlang.org/docs/reference/multiplatform.html Example from the doc
by EddieRingle 9y ago
Multiplatform docs here: https://kotlinlang.org/docs/reference/multiplatform.html https://kotlinlang.org/docs/reference/multiplatform.html
Example from the docs:
// Common module
package org.jetbrains.foo
expect class Foo(bar: String) {
fun frob()
}
fun main(args: Array<String>) {
Foo("Hello").frob()
}
// JVM module
package org.jetbrains.foo
actual class Foo actual constructor(val bar: String) {
actual fun frob() {
println("Frobbing the $bar")
}
}
I brought up how I thought the `expect` and `actual` keywords (but primarily the latter) added unneeded verbosity in the Kotlin Slack awhile back and was pretty much shrugged off, despite folks on the Kotlin team admitting that they exist in part to make the IDE's job easier, but weren't actually necessary.
It leaves a sour taste in my mouth, but I suppose it might be because I'm familiar with projects in C/C++ where, if a symbol goes undefined, the compiler/linker is smart enough to tell you that without being hand-held.
- pjmlp 9y agoYou are not alone. I also believe they could have manage it without polluting the code with expect and actual. Probably the compiler would need some extra work to do the matching.
- oblio 9y agoTrue, but on a scale of 1 to 10, with 10 being amazing, Kotlin is quite high, maybe an 8, and your point is only a minor nit.
- noncoml 9y agoYou seem very fond of Kotlin. I hear a quite a bit about it lately, but as I haven't had the chance to play with it yet, I was wondering why would one choose it over Scala.
- pjmlp 9y agoWhen doing Android development. Kotlin has gotten official support from Google, including documentation as part of Android SDK.
- barrongineer 9y agoI find it to be more pragmatic and easier on the eyes. It's easier to learn and also being adopted by more mainstream ecosystems like Spring, Android, Gradle, etc. IDE support is obviously top-notch as well.
- yole 9y agoIt's not really "to make the IDE's job easier", it's to make it explicit that the given class needs to match a certain contract, and to make the validation errors more clear.
- seanmcdirmid 9y agoSo expected is import and actual is export in unit module parlance?
- yole 9y agoIt's a bit different from a regular export/import relationship. An exported declaration is usually made visible to an unlimited number of clients, and an actual declaration matches a single specific expect declaration.
- seanmcdirmid 9y agoThat’s why I said units, as in program units (Flatt, Findler, etc...). I added a module system to java that did the same thing using light bytecode rewriting in the linking step (kotlin seems to do structural matching, but doesn’t have a reconfigurable linker I guess); https://dl.acm.org/citation.cfm?id=504311.504298 https://dl.acm.org/citation.cfm?id=504311.504298.
- agumonkey 9y agothat is so verbose I still can't believe it's true. sorry actually true
- bitL 9y agoThat's silly. I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity. I was thinking about using Kotlin for multiplatform stuff but now I'll likely look elsewhere...
- coldtea 9y ago>I guess devs got lazy and decided to go with a convenient wart instead of conceptual purity Aka pragmatic. But it can all be fixed -- you can do a hostile fork and improve upon their code together with other non-lazy developers. You'd get much more done than the Kotlin team, being non-lazy and all...
- bitL 9y agoHostile fork has a low chance of survival; for one you should wait until Google cuts all vital pieces off JetBrains as they are trying for the past few years anyway, yet making JetBrains people somehow flattered about it... MS is at least openly trying to kill them.
- _pmf_ 9y agorequirement outjection vs. dependency injection
- sjrd 9y agoI know precisely why they did this. They did it because IntelliJ cannot cope with a file being part of two different modules. Scala/JVM + Scala.js has been sharing code for almost three years now, and it works perfectly out-of-the-box in Eclipse. However, in IntelliJ they barely made it kind-of work by creating an artificial `shared` module (in addition to the normal `jvm` and `js` modules) that `jvm` and `js` depend on. But `shared` cannot see the definitions from `jvm` and `js` with that model. [1] So because IntelliJ cannot deal with shared source files, they bastardized the language to work around that limitation. They really should have fixed the IDE instead. [1] https://youtrack.jetbrains.com/issue/SCL-7859 https://youtrack.jetbrains.com/issue/SCL-7859