Hacker News new | ask | show | jobs
by yole 3122 days ago
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.

1 comments

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

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.