Earlier quoted context omitted.
It'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.
So expected is import and actual is export in unit module parlance?
Kotlin 1.2 Released: Sharing Code Between Platforms
11–20 of 41 posts
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#12- server side render a page to HTML and send it to browser, or
- send down the React code as JS and render in browser, or
- use React Native to write sorta native Android/iOS apps and reuse some of my JS codebase
Does Kotlin cover the same use cases of server-side render & browser render & native mobile apps?
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#13Earlier quoted context omitted.
So expected is import and actual is export in unit module parlance?
It'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.
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#14How does Kotlin multiplatform compare to React? In React I can: - server side render a page to HTML and send it to browser, or - send down the React code as JS and render in browser, or - use React Native to write sorta native Android/iOS apps and reuse some of my JS codebase Does Kotlin cover the same use cases of server-side render & browser render & native mobile apps?
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#15I really like some of Kotlin's decisions, but I prefer Haxe's approach to this. For single target code, you can prefix the class module with the platform tag (e.g. "js" or "java"). These module names are reserved within the compiler and any code therein is restricted to their respective targets. Another way is to use conditional compilation markers to indicate specific target-compatible boundaries. E.g. #if java publ…
In Kotlin, every module contains either common code or platform-specific code. I'm not sure why you consider the module-level distinction to be less clean than being able to mix common and platform-specific code randomly within a single file. And your example shows that there is no way to verify that each module provides a consistent API.
Module-level distinctions are per-target. It doesn't get any more clean and clear than that, does it? The trade off is that it's a bit limiting. Conditional compilation is where you can start to pick and choose targets/features and handle more sophisticated cases.
> And your example shows that there is no way to verify that each module provides a consistent API.
This is easy to do by providing a common interface definition and a simple build class that targets each language you're interested in. It's a good idea in a formal testing suite for a complex library.
I only do that in a handful of projects though, most of the time cross-target code is just a few special exceptions. In that case, you'd call out the special case, and then use the #else directive for the rest:
#if java
public inline function print(s : String) java.lang.System.out.println(v);
#else
public inline function print(s : String) Sys.println(s); // most of the time basic ops are covered by std lib.
#end
FWIW I've "inlined" things here with the keyword. This lets you alias cross-platform methods like this without extra function call overhead.Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#16How does Kotlin multiplatform compare to React? In React I can: - server side render a page to HTML and send it to browser, or - send down the React code as JS and render in browser, or - use React Native to write sorta native Android/iOS apps and reuse some of my JS codebase Does Kotlin cover the same use cases of server-side render & browser render & native mobile apps?
You can do isomorphic (server-side and client-side) rendering in Kotlin. For mobile UI, you can build native UIs in Kotlin for Android and for iOS, but the UI code will be different for each platform, built on the native API of the corresponding platform. At this time we have no plans to build a solution for reusing UI code between mobile platforms.
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#17Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#18> "Working with the Command Line Compiler" https://kotlinlang.org/docs/tutorials/command-line.html > "We can download it from GitHub Releases." https://github.com/JetBrains/kotlin/releases/tag/v1.2 404
We've fixed this already; the fix is being deployed. The correct URL is https://github.com/JetBrains/kotlin/releases/tag/v1.2.0
$ which kotlinc
/opt/src/kotlin-1.2.0/bin/kotlinc
$ kotlinc
/usr/bin/env: ‘bash\r’: No such file or directory
Seems to have been saved with MS Win line ends, which causes a problem with bash on Ubuntu.Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#19Earlier quoted context omitted.
You can do isomorphic (server-side and client-side) rendering in Kotlin. For mobile UI, you can build native UIs in Kotlin for Android and for iOS, but the UI code will be different for each platform, built on the native API of the corresponding platform. At this time we have no plans to build a solution for reusing UI code between mobile platforms.
If I can't reuse code between iOS & Android then what is the benefit of using Kotlin over just building mobile apps in Java & Swift?
Re: Kotlin 1.2 Released: Sharing Code Between Platforms
#20Earlier quoted context omitted.
We've fixed this already; the fix is being deployed. The correct URL is https://github.com/JetBrains/kotlin/releases/tag/v1.2.0
$ which kotlinc /opt/src/kotlin-1.2.0/bin/kotlinc $ kotlinc /usr/bin/env: ‘bash\r’: No such file or directory Seems to have been saved with MS Win line ends, which causes a problem with bash on Ubuntu.