There is an package in Kotlin for continuations, but it's marked as experimental. There is no documentation other than the API, and no tutorial or examples anywhere that I could find. Does anyone know if it's already usable? What would be an example of its usage?
The Continuation interface is a part of coroutines support API in the standard library. You can start exploring the coroutines from the documentation page, or from the kotlinx.coroutines library repository, which contains an extensive coroutine programming guide.
Coroutines are experimental in Kotlin 1.1 and 1.2, but there was an announcement that they are going to stabilize in 1.3.
When you say "continuations", you actually mean "coroutines". Continuation is a part of that story.
kotlin-coroutines-informal by the JetBrains team is a great resource to start you off with coroutines. If you're looking to use them for async programming on Android, especially take note of the section on wrapping the callbacks which your existing async API provides, turning the existing Java function calls into Kotlin suspend funs.
About the status of experimental, check out Roman Elizarov's answer to that question. Here's a highlight:
Kotlin coroutines can and should be used in production. That was the chief reason to officially release them in Kotlin 1.1. Having released them, the JetBrains team had committed to maintain backwards compatibility with respect to any changes that are introduced to them in the minor releases as they evolve, while allowing people to safely try them in complex production applications.
There is absolutely no reason to wait for 1.3 to start using coroutines. Whatever you write today will work into the foreseeable future with no changes and, on top of that, it will be very easy to switch from kotlinx.coroutines.experimental to kotlinx.coroutines after the release. The APIs are already very stable and most of the changes are now in the area of channels and actors.
Related
I am working on a Java-based library, and I'd like to start using Kotlin. However, there are over 10k known direct consumers, and I don't want to introduce a new dependency to all of the consumers.
For consumers that are already using Kotlin, I especially don't want to force them to upgrade or downgrade their Kotlin Stdlib version in order to use the latest version of the library, or introduce a classpath conflict of any sort.
Is it possible to use Kotlin in a way that doesn't "export" a new dependency to all of the library consumers?
My question is similar to
Using Kotlin libraries as dependencies in a Java project, but it (a) does not have an accepted answer, and (b) is trying to completely hide the existence of Kotlin types from Java consumers whereas I'm just trying to avoid causing any conflicting dependency requirements.
I'm currently using Maven, but wanting to switch to Gradle. A solution that works for Maven or Gradle is acceptable since using Kotlin is of greater importance than using a particular build system.
I ask the above question to avoid posing an XY Problem. My theoretical solution is to shade/relocate a specific version of the Kotlin Stdlib—but is it even possible, given that the Kotlin Stdlib seems to have some special treatment in the Kotlin compiler?
There is almost an exact match of this question on the Kotlinlang discussion board (What is the proper way to repackage/shade Kotlin dependencies), but it also does not have an answer.
Digging into the codebase of Arrow I found this deprecation warning above higher-kinded types.
Higher Kinded types and their related type classes will no longer be
supported after Arrow 0.13.0. Most relevant APIs are now concrete over
the data types available as members or top level extension functions
Can anyone motivate this choice and the proposed alternatives? Or point me to some relevant documentation on this topic?
Raul Raja wrote this about it on the Arrow-channel in the Kotlin-slack:
For those wondering about the future of Higher Kinds in Arrow:
Kinds are going away because their encoding forces the user to call .fix() and there is no workaround for it without compiler plugins.
Once compiler plugins are properly supported perhaps after 1.5 then we will revisit kinds but instead of providing all this boilerplate we will provide a deeper and better integration than what we have now. Arrow Meta already has this support but it can’t be distributed to users until the Kotlin IDEA plugin supports compiler plugins. Kinds will be revisited then.
Since Arrow is currently marching close to the final encoding of 1.0, we can’t release a 1.0 where the entire lib and most of user code depends on Kinds in the current form and commit to maintain that for the long run.
I read the Big Nerd Ranch guide to Kotlin and it talked in several places about Kotlin/Java interop, but never JS or native. I already had a solid background in Java, so I have gotten used to using Java classes in my Kotlin code. I am trying to write a Kotlin program which will be run on a site where most - if not all - functionality is written in JavaScript, and I am trying to understand how to write my code to make sure that it is interoperable. Will I be able to continue using Java classes in my Kotlin/JS code? What are the differences between writing Kotlin/JVM code and Kotlin/JS code? What should a (ex-) java programmer know when learning to interop with JS using Kotlin? If there are a few chapters on this in any good books written in the recent past, that would be helpful also.
As Steve already mentioned, you can't utilise java classes in Kotlin/JS.
Think of Kotlin/JS as Typescript.
It provides a different syntax to write code that ultimately compiles to JS.
Here are the notable differences of writing Kotlin/JS code vs Kotlin/JVM code
Kotlin/JS internally uses yarn for dependency management. This enables you to depend on any javascript module available on npmjs etc (see note below)
In addition to standard library, you can also leverage other kotlin-first frameworks such as kotlinx-serialization, ktor etc
Testing libraries will be JS specific. So instead of mockito / mockk / junit family, you'll need to get familiar with karma / mocha family.
There will be a difference in Coroutine capabilities - both in terms of the way one writes code and performance expectations.
I found reading about Kotlin Multiplatform helped clarify a lot about the capabilities of kotlin.
I know this was not specifically asked, but giving my 2cents to people considering Kotlin/JS (as of Sep'20)
Great if you're familiar with Kotlin and don't foresee too many third party dependencies apart from http i/o (ktor) , React ( kotlin-react) and basic html / css (covered by kotlin-styled).
Using JS modules as dependencies is not as straight forward as using JVM dependencies since there is no ready-made interop. One has to define javascript functions/classes in kotlin before using them (see here). So if you foresee leveraging a lot of existing javascript modules, it won't be an ideal way forward.
Great if you have a typical backend-frontend model where backend compiles to JVM and Frontend compiles to JS. You can leverage a common data model and http i/o framework across Backend and Frontend code (via Kotlin Multiplatform). I've found this to be a tremendous productivity boost!
Kotlin/JS compiles Kotlin code, including its own standard library, into Javascript code. At the end, that's all you have is Javascript. What you don't have is any connection to the Java Virtual Machine. Kotlin's standard library provides no magic to bridge Javascript code to the JVM so that it can utilize Java classes. So NO, you can't utilize Java classes in standard Kotlin/JS.
So I'm working on updating a large project from really old C++/Carbon code, and I keep running into deprecated functions.
So I guess there are 2 aspects to this question.
The immediate question is:
What should be used instead of the following functions which were deprecated in 10.7? Are there Cocoa equivalents, or updated Carbon equivalents?
MPCreateEvent
MPDeleteEvent
MPWaitForEvent
MPSetEvent
And the second part of the question is, is there some place on the Apple developer site - or elsewhere - that I can find more information about what should be used in cases where old code is officially deprecated?
First off, you should read the Concurrency Programming Guide. There are several ways to achieve concurrency in Cocoa apps and that guide explains them all in detail.
Probably the closest analogue to the Carbon functions are the various Grand Central Dispath (GCD) functions, which allow you to run code in a background process by passing an Objective-C block:
dispatch_queue_t aQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(aQueue, ^{
NSLog(#"Do some work in the background here.");
});
This is all explained in detail in the concurrency docs. Unfortunately, I was unable to find any documentation about the deprecation of the Multiprocessing API. However, that API is very old, dating back to before Mac OS X, and I suspect Apple are assuming that most of the code using it is long-dead. I don't envy you your task!
Note that GCD and blocks were introduced in 10.6. If for some reason you need to support 10.5, you can use the NSOperation methods which were introduced in that version of the OS. These are not as easy to use as GCD but they can achieve a similar result. NSOperation is still available and very good for certain use cases.
When the developer of an API, e.g., Microsoft, Apple or me, announces a feature of the API is being deprecated, how long should the API developer wait before removing the feature from the API?
From the other point of view, how long should a user of an API expect to have to refactor code after an API feature is marked as deprecated?
If you move from version A to B, you should directly remove deprecated methods.
Unless you know that you won't need later upgraded version then you may keep what's working.
But as every problem, the sooner you take them on, the easier it'll be.
It's usually easy enough to change deprecated code from version A to B, but if you cumulate modifications, it'll be a nightmare
Once you discover APIs that are marked as deprecated, you should start looking to update your software to replace them with non-deprecated methods. If you continue to use them, you run the risk of your software not working on newer versions. This is fine if you never plan on upgrading, as evidenced by the multitude of Win 3.1 software still in use. However, if you are going to be supporting the software or releasing new versions, you should update as soon as feasible.
Usually, the API never removes features due to the fact that some programs will be rendered useless if they rely on a certain method. But if the method is honestly useless or contains a lot of bugs, they remove it after two or three updates.