Comments (14)
My issue with coroutine dispatchers not being organized in a hierarchy is poor discoverability. For example, if I want to use a coroutine builder, but forgot the spelling of a dispatcher I need, there is currently no better option than reading the documentation.
I propose to introduce a global singleton Dispatcher
for serving as a hierarchy root. Then all coroutine dispatchers can be its extension properties val Dispatcher.Unconfined get() = ...
and be used as Dispatcher.Unconfined
.
The cost is that we have to use the prefix. The benefit is that IDE now lists all dispatchers for me.
from kotlinx.coroutines.
I like the flexibility of @LouisCAD's suggestion. Being able to provide both Android.Main
(async) and Android.UI
(vsync) dispatchers, but I agree with @adamp in #427 (comment) that having two dispatchers would be confusing too.
I still think Dispatchers.Main
is an unfortunate name since it's such a generic noun. Maybe Dispatchers.Android
to be similar to JavaFx
and Swing
?
from kotlinx.coroutines.
There is also a related issue of naming various functions that take dispatchers as their arguments. Might renaming run
to runOn
help? See also discussion here: https://discuss.kotlinlang.org/t/calling-suspending-function-from-regular-function/3670
from kotlinx.coroutines.
I've reopened this discussion in light of structured concurrency (#410) and the proposed change for the Android dispatcher (#533). The goal is to address two concerns:
- Discoverability of different dispatchers.
- Readability of the code, given the fact that dispatcher is always passed as
context
parameter and there are different types of context element, so it may not be visually obvious which one is a dispatcher.
The concrete proposal I have on the table is to group all the dispatcher references under Dispatchers
object:
Dispatchers.Default
— a default dispatcher for background asynchronous tasks (currently backed byCommonPool
, a new dispatcher in the future).Dispatchers.IO
— a dispatcher for blocking background operations (#79).Dispatchers.Main
— a dispatcher for Android Main Thread (#533).Dispatchers.Swing
— a dispatcher for Swing Event Dispatch Thread.Dispatchers.JavaFx
— a dispatcher for JavaFx Application Thread.
from kotlinx.coroutines.
I think Dispatchers.Main
is going to confuse people. Maybe Dispatchers.Android.Main
to make it clearer?
from kotlinx.coroutines.
While Dispatchers.Android.Main
is a bit more verbose, it is more consistent against Dispatchers.JavaFx
and similar, and allows for Dispatchers.Android.UI
extension to access the default UI thread with vsync if needed (see #507).
As LifecycleOwner
s (Activity
, Service
, etc) are probably going to be CoroutineScope
s by themselves, they would default to Dispatchers.Android.Main
, so you'd most likely never have to write it by yourself in your codebase.
from kotlinx.coroutines.
@chrisbanes Let me clarify, that Dispatchers.Main
is going to be available only when you program for Android and add kotlinx-coroutines-android
dependency, so there should not be any confusion about which Main
is that. On the other hand, both JavaFx
and Swing
can be available when you program for Java Desktop, for example, that is why they are named in a more explicit way.
from kotlinx.coroutines.
I'm not convinced that a potential name clash is actually a problem. Can you give some examples as to where you have encountered it?
The argument against this change is that dispatchers are exclusively used as arguments to various coroutine builders: launch
, async
, produce
, etc. This particular usage context gives enough disambiguation to make any kind of "Dispatcher" suffix superfluos (or so it seems).
from kotlinx.coroutines.
Hi @elizarov,
I have a problem naming a Vert.x's dispatcher, following current convention its name should be "Vertx"?
Any suggestion in well accepted, thanks.
from kotlinx.coroutines.
I'd give it a short name, like Vx
. However, I'm still keeping this naming issue open to review the naming before we finalise 1.0 version of kotlinx.coroutines
. Short names might be good for slide-ware, but it is not that clear-cut for a larger project.
from kotlinx.coroutines.
This issue raised on my first approach on coroutines.
If we consider Java's List then we can have ArrayList, LinkedList, EmptyList and so on. It is simple to aggregate all these on a single cap.
"Unbounded" and "Swing" are too heterogeneous names, and the argument for "async" method is "CoroutineContext" not "CoroutineDispatcher", so I can wrongly use "Swing" as a coroutine's L&F.
In simple case the code a trained programmer can understand correctly the statement: produce(Unconfined) ...
I fear that in more complex use case a wrong name can lead to confuse code.
from kotlinx.coroutines.
@voddan That is an interesting idea. I like it more than just giving them longer names. like XXXDispatcher.
from kotlinx.coroutines.
I agree that the coroutine dispatcher naming conflict isn't really an issue. It's somewhat nice that it's short and sweet for something that will be commonly used: launch(UI) { ... }
from kotlinx.coroutines.
Closing this issue. We'll leave the general naming approach as it is (a few top-level names).
from kotlinx.coroutines.
Related Issues (20)
- 1.9.0-RC test task:compileDemoDebugUnitTestKotlin error Suspension functions can only be called within coroutine body. HOT 1
- Improve invokeOnCompletion and invokeOnCancellation API HOT 1
- Mention `testScope.backgroundScope` in `UncompletedCoroutinesError`
- Allow `Dispatchers.Unconfined` to use the event loops as time sources
- Add optional support for Micrometer Context Propagation
- `withContext` may execute code in the wrong context if the `coroutineContext` misleads it HOT 3
- SharedFlow doesn't have same parameters as in constructor function HOT 2
- Consider deprecation cycle for `CoroutineDispatcher.invoke` HOT 6
- How to prevent a SharedFlow collect values when the activity resumes? HOT 1
- Consider discouraging `CoroutineStart.LAZY`
- Some problem about `addLast` in LockFreeTaskQueue HOT 1
- Maybe it's reasonable to recommend wrapping a `callbackFlow` initialization into `try`-`finally`? HOT 4
- Dispatcher failures may leave coroutines uncompleted HOT 1
- `DelayWithTimeoutDiagnostics` missing from R8 rules? HOT 3
- Introduce Flow.all/any/none operators HOT 3
- [WASM] JsException: Exception was thrown while running JavaScript code kotlinx.coroutines.error_$external_fun HOT 6
- Suppressed exceptions are lost during stacktrace recovery HOT 1
- `runBlocking` executes other tasks instead of its own HOT 1
- "Kotlin Compiler Error: NoClassDefFoundError for kotlin/reflect/full/KClasses during Gradle build" HOT 1
- Add argument to sample to sample at the start of a flow instead of the end? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kotlinx.coroutines.