Closed ultraon closed 2 years ago
Hello @ultraon and thanks for the idea!
First of all I would like to stress, that providing the CoroutineScope
as a property
was an explicit design decision. Making custom classes to implement CoroutineScope
is discouraged, according to docs, various messages in Slack and some articles: Docs page, A slack thread, An article. The main reason is that it's error prone, you my accidentally launch a coroutine in incorrect scope.
Passing a scope via constructor - currently I find this also not a good API. CoroutineExecutor
closes the scope on dispose. Currently CoroutineScope
is encapsulated (owned and controlled by the CoroutineExecutor
), and so its lifetime is guaranteed to be between CorutineExecutor
instantiation and disposal. Passing CoroutineScope
via constructor removes ownership from CoroutineExecutor
.
If you still really won't to implement CoroutineScope
, then maybe you can create your own base class?
open class BaseExcecutor(...) : CoroutineExecutor(...), CoroutineScope by scope {
...
}
It’s a pretty good explanation, thank you.
Hello Arkadii, thanks for this great library. I have a suggestion to improve the
CoroutineExecutor
contract, literally, it simplifies the usage of explicitscope
property.Then we can use
CoroutineExecutor
in this way:To do that with existing contract I should: