What do you good people think of this? <https://tw...

# coroutines

[pablisco]

What do you good people think of this?
https://twitter.com/pablisc0/status/1148866357188055040?s=19

[gildor]

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)

[gildor]

I would create a feature request on kotlinx.coroutines issue tracker

[hmole]

Second snippet is less readable. Looks like your typical future chain

[gildor]

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:

also { withContext(Main) {} }

[gildor]

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`…

[Paulius Ruminas]

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.

[Dico]

It would not be the same as Future/Promise style because you are not limited to the operators

[Dico]

It does look closer to it though

[Dico]

I think letWithContext should be treated with more priority here

[Robert Menke]

I like the way the 2nd snippet reads fwiw

[gildor]

alsoOn doesn't break the chain, it returns receiver

[Paulius Ruminas]

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?

[pablisco]

Well, if you look at the gist attached you can see that I made a version for all the scope functions.

[pablisco]

Also, they are all suspending functions

[pablisco]

Also, @Paulius Ruminas, updating the Ui is literally a side effect 😄

[wickedev]

I think this makes more sense. https://gist.github.com/wickedev/58b160fb5752897776a310734ad5c2b4

[gildor]

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

[wickedev]

Sorry. My mistake. I just thought of it in my head without run. I fixed it right now.

[wickedev]

message has been deleted

[gildor]

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

[gildor]

I also would say that it really depends on how updateUI is implemented

[wickedev]

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.

[wickedev]

If you prefer a functional style, would not RxJava be better than a coroutine?

[Paulius Ruminas]

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.