Hmm You can often see the first one in docs but I m concerne

Question

Hmm You can often see the first one in docs but I m concerned that it doesn t scale well Consider this ``` fun main runBlocking with First with Second with Third foo zip bar zip foo fails because of name conflict class First fun CoroutineScope foo ReceiveChannel lt Int gt class Second fun CoroutineScope bar ReceiveChannel lt Int gt class Third fun CoroutineScope foo ReceiveChannel lt Int gt ``` Deep nesting plus name conflicts How do you tell the difference between the two methods with the same name

gildor · Answer

If you have such extreme cases just use parameter instead it s just matter of style

gildor · Answer

I believe mostly people vote for the first one because it consistent with other coroutines builders

gildor · Answer

Also I m not sure that general approach when each method of class is coroutine builder is so common Maybe if you have class you can pass scope to constructor this is not universal solution but on practice I see it often when if I have class with coroutine builders class itself has some state inside exposed with channels so class should have own scope to handle lifecyle so it solves code problem because you don t need scope anymore Of course it s not something universal but maybe if your class doesn t have internal state and each method is standalone buildrr better just use top level functions for those builders

ghedeon · Answer

a concrete usecase viewmodel consumes data from repository So all these classes that provide channels are repositories Having this combining 3 streams from a repo is not an extreme case The intention was pretty clear viewmodel has a scope and lifecycle It pulls all the data delivers to main thread and knows when to clean It works but as you can see the API gets pretty messy As you mentioned I was thinking of having repository implement it s own `CoroutineScope` but there is no lifecycle attached to it What about the cleanup in this case Do you still have to do anything about the Job

Dico · Answer

Was I mentioned here or something I m a bit confused

Dico · Answer

Anyway I think if you re calling 3 coroutine builders in one line you are probably doing something wrong anyway

Dico · Answer

Oh you linked it nvm

ghedeon · Answer

< Dico> the code is here it s written according to docs and it s a few simple lines I gave the actual usecase in every second android app a few seconds ago `Something wrong anyway` is not very constructive

Dico · Answer

Okay sorry I didn t intend it as criticism it just struck me as an edge case

dave08 · Answer

Maybe surround each `produce` in a `coroutineScope ` to use the callers scope < ghedeon>

gildor · Answer

This doesn t make sense coroutineScope will never return if there is some active produce coroutine

gildor · Answer

gt What about the cleanup in this case Do you still have to do anything about the Job Just pass coroutine scope as argument

gildor · Answer

you also can do some trick like return some ChannelProvider and subscribe already in your scope but not sure that this additional abstraction make sense

dave08 · Answer

Good catch < gildor> blush in the end it looks like he s right that rx leads to a cleaner api in this regard I wonder if cold channels would solve this

gildor · Answer

gt it looks like he s right that rx leads to a cleaner api in this regard It s not true Rx by default do not force you to handle lifecycle You can do exatly the same with Kotlin if you want `fun bar = GlobalScope produce ` this is exactly what RxJava does in terms of lifecycle

gildor · Answer

forcing user to handle lifecycle explicitly is good and this is why structured cconcurrency exists

gildor · Answer

`fun bar scope CoroutineScope = scope produce ` is not worse than `fun CoroutineScope foo = produce ` This is just a matter of style and use case

dave08 · Answer

Good point but in rx you handle the lifecycle at subscription using composite subscriptions coroutines force you to handle it in the repositories and in all usages you can t just delegate handling to the usage side like in the viewmodel so you end up with scopes all over the place That s why I think cold channels might solve this < gildor>

gildor · Answer

gt but in rx you handle the lifecycle at subscription using composite subscriptions ```val compositeChannel MutableList lt ReceiveChannel lt T gt gt compositeChannel = GlobalScope produce do some subscription compositeChannel forEach it close ```

gildor · Answer

gt coroutines force you to handle it in the repositories and in all usages And this is good not bad

gildor · Answer

This is not a problem of channel at all This problem because `produce` runs coroutine

gildor · Answer

you right with cold streams it may be something different but the only thing that changed is that you pass scope to some `subscribe ` method

dave08 · Answer

That s the current advantage of rx cold channels seem to be blocked for some reason I think it s a pity

gildor · Answer

what

gildor · Answer

I mean cold and hot streams are diffrent

gildor · Answer

and yeah rxjava supports also cold

gildor · Answer

I just don t understand how this related to discussion

dave08 · Answer

I mean they re not implementing it there s lots of talks in the issue on github the relationship is that it would be a cleaner solution to the original question

gildor · Answer

Are we talking about lifecycle handling and code style of coroutines builders or hot vs cold

gildor · Answer

because it s completely not related for me

ghedeon · Answer

< gildor> when you say it s a matter of style does it mean there is a way to distinguish same function names `foo foo` in my example Because I didn t find it yet Only the last one wins

Dico · Answer

Well you can use this syntax and I believe it s only a problem with signature clash

gildor · Answer

no unfortunately you cannot use this

gildor · Answer

You can do something like with Second with First foo zip bar zip with Third foo

gildor · Answer

And this is ugly for sure But it really depends on real code Your particular example can be rewritten

gildor · Answer

``` val firstFoo = with First foo val bar = with Second bar val thirdFoo = with Third foo firstFoo zip bar zip thirdFoo ```

ghedeon · Answer

oh well I think that s where I draw the line it s not a matter of style anymore slightly smiling face One is working and another is mental gymnastic

gildor · Answer

You just need somehow call function

gildor · Answer

Someone may say it s fine

gildor · Answer

someone will just rewrite to ``` val firstFoo = First foo scope val bar = Second bar scope val thirdFoo = Third foo scope firstFoo zip bar zip thirdFoo ```

gildor · Answer

is it much better Maybe in this case yes

gildor · Answer

But code does exactly the same

ghedeon · Answer

come on it IS better Like objectively

gildor · Answer

But if you have class and use a lot of methods ``` class First fun CoroutineScope foo = produce fun CoroutineScope bar = produce fun CoroutineScope baz = produce ``` Than usage with sccope is quite nice ``` with First foo zip bar zip baz ```

gildor · Answer

it s better but for this particular extereme case

gildor · Answer

`with` is just a way to bring extension to scope nothing more

gildor · Answer

why not just use param for scope if it works better for your use case and for your style preferences

ghedeon · Answer

I will but I m here to understand what I can do with channels what are the good practices so I can give answers to my team not to solve a boring repository request I d kindly ask you stop pushing for extreme case It s a day to day case and a corner stone of Rx usage It s basically every second Interactor in your app take a few repos combine channels give it to ViewModel The earlier we aknowledge this the faster we can adapt and maybe address it in official documentation because now it s only top level functions there

ghedeon · Answer

needless to say that I appreciate your contribution to this community it s a titanic effort

gildor · Answer

okay not extreme synthetic case that doesn t work well with current code

gildor · Answer

I would just choose style on particular use case

gildor · Answer

gt It s basically every second Interactor in your app take a few repos combine channels give it to ViewModel And all your sources of observables have name conflicts Not every ViewModel has so many separate sources of course it s possible I just want to say that it not something that you have all the time

gildor · Answer

And I don t want argue that extension function is better for repository case it s not this is why I m talking about style That there is no universal answer same way as with any other function vs extension usage

bdawg.io · Answer

Afaik given a function `class Foo fun CoroutineScope bar = ` can be invoked as `foo bar scope ` without rewriting the extension function signature

Dico · Answer

I don t believe that s correct I think you can do it with lambdas with a receiver but not functions with receivers

elizarov · Answer

It is not possible and there are other use case where it might be desired though See also discussion on this issue <https youtrack jetbrains com issue KT 14504>