Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin 1.2 Released: Sharing Code Between Platforms

blog.jetbrains.com

Post reply on HN
Print view View original

1–10 of 41 posts

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#2

Post by EddieRingle »

Multiplatform docs here: 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) {
      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.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#3

Post by pjmlp »

EddieRingle wrote: post #2

Multiplatform docs here: 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 ) { 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 `…

You 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.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#4

Post by oblio »

pjmlp wrote: post #3
EddieRingle wrote: post #2

Multiplatform docs here: 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 ) { 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 `…

You 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.

True, 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.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#5

Post by yole »

EddieRingle wrote: post #2

Multiplatform docs here: 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 ) { 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 `…

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.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#6

Post by seanmcdirmid »

yole wrote: post #5
EddieRingle wrote: post #2

Multiplatform docs here: 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 ) { 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 `…

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?

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#7

Post by jdonaldson »

I 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
     public function print(s : String) java.lang.System.out.println(v);
  #end
That method only exists on the java target, and the compiler will complain otherwise.

Conditional compilation also allows for more fine-grained support of multiple targets:

  #if java
     public function print(s : String) java.lang.System.out.println(v);
  #elseif js
     public function print(s : String) console.log(v);  // as a simple example
  #end
This makes a cleaner organizational distinction between extern code that must remain target specific, and true cross platform code that can be called on any of the supported targets. Editors can pick up on this very easily and provide early warnings as you are typing, and doc generators can also inspect these directives and show api availability between targets in the rendered docs.

(self-disclosure: Haxe compiler contributor)

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#9

Post by yole »

jdonaldson wrote: post #7

I 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.

Re: Kotlin 1.2 Released: Sharing Code Between Platforms

#10

Post by yole »

igouy wrote: post #8

> "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
Post reply on HN