https://kotlinlang.org logo
#coroutines
Title
# coroutines
p

pablisco

07/10/2019, 8:13 AM
2
g

gildor

07/10/2019, 8:16 AM
Make sense for me for chain operators. But naming is hard, semantically it’s
alsoWithContext
, but probably a bit long (for already quite long withContex)
I would create a feature request on kotlinx.coroutines issue tracker
👍 5
h

hmole

07/10/2019, 8:51 AM
Second snippet is less readable. Looks like your typical
future
chain
👍 2
g

gildor

07/10/2019, 8:53 AM
yes, it’s a chain, and existing Kotlin extensions like also/apply/let/run are done exactly for this, it’s just a shortcut for:
Copy code
also { withContext(Main) {} }
But it’s actually one more concern, should coroutines also provide let/apply/run versions of this extension,
let
is definitely needed if we have `also`…
👍 2
p

Paulius Ruminas

07/10/2019, 10:55 AM
Before looks more clear then after.
alsoOn
breaks the "chain" and has no return type. This looks like
Future\Promise
style API which you can avoid by using suspending functions. For me at least that is why coroutines are so awesome because you can avoid the
Future\Promise
style of code.
👍 1
d

Dico

07/10/2019, 11:41 AM
It would not be the same as Future/Promise style because you are not limited to the operators
It does look closer to it though
I think
letWithContext
should be treated with more priority here
r

Robert Menke

07/10/2019, 1:45 PM
I like the way the 2nd snippet reads fwiw
g

gildor

07/10/2019, 2:07 PM
alsoOn doesn't break the chain, it returns receiver
p

Paulius Ruminas

07/10/2019, 4:52 PM
alsoOn doesn't break the chain, it returns receiver
ohh it works like
.also { ... }
and returns the previous value. But is a function like
also
considered an operator function? It is mostly used for side effects. I considered an operator function to be like
F(x) = Y
not
F(x) = F(x)
. Is there a definition for what "operator function" is?
p

pablisco

07/10/2019, 5:35 PM
Well, if you look at the gist attached you can see that I made a version for all the scope functions.
Also, they are all suspending functions
Also, @Paulius Ruminas, updating the Ui is literally a side effect 😄
w

wickedev

07/11/2019, 2:50 AM
g

gildor

07/11/2019, 3:14 AM
GlobalScope.withContext doesn’t exist and in general doesn’t make sense, because or it’s launch/async and new coroutine or just withContext that just wrap suspend call Also it’s pretty bad style to launch one more coroutine on GlobalScope when you already have scope in
launch
w

wickedev

07/11/2019, 3:32 AM
Sorry. My mistake. I just thought of it in my head without run. I fixed it right now.
message has been deleted
g

gildor

07/11/2019, 3:55 AM
Why do you need all those DslMarkers and why do you hide launch implementation? it looks not good for me. Client should be always explicit about scope
I also would say that it really depends on how updateUI is implemented
w

wickedev

07/11/2019, 4:00 AM
Since I have a background in async/await in JavaScript and C#, I think the coroutine should be more concise (no matter where it is executed), so the beginning of the coroutine should be main.
If you prefer a functional style, would not RxJava be better than a coroutine?
p

Paulius Ruminas

07/11/2019, 5:58 AM
Also, @Paulius Ruminas, updating the Ui is literally a side effect
Yes that's why I personally don't like chaining it with data transforming operations. 🙂 That's why I think before snippet is more clear. I don't really see the point of making an extension function for that reason. But probably there is no "better" way here some people will like the before snippet some will like the after snippet.
2 Views