CoroutineDispatcher's names

[fvasco]

CoroutineDispatcher's names are too heterogeneous (CommonPool, Unconfined) and programmer isn't helped to collate these in the same hierarchy.
Other CoroutineDispatchers have too common name (Swing, JavaFX) and are subjects to name clash: Look And Feel engine can also expose "Swing" and "JavaFX" singletons.

My prosose is to define a common suffix like "CoroutineDispatcher", "CDispatcher" or simply "Dispatcher" to grouping names.

I.E.

1. CommonDispatcher
2. UnconfinedDispatcher
3. SwingDispatcher
4. JavaFXDispatcher

launch(CommonDispatcher) {
    . . .
}

[elizarov]

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

[fvasco]

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.

[fvasco]

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.

[elizarov]

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.

[elizarov]

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

[voddan]

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.

[elizarov]

@voddan That is an interesting idea. I like it more than just giving them longer names. like XXXDispatcher.

[ScottPierce]

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) { ... }

[elizarov]

Closing this issue. We'll leave the general naming approach as it is (a few top-level names).