(just saw your earlier reply @Ruckus. It looks like there is a threading feature which collapsed under @edvin's psot)

@carlw Sorry about that. Slack's threading is weird.

What do you think of this use case @edvin? And is it handled with openModal? 1. Call a service asynchronously to retrieve a list of fake game servers 2. Display a prompt to select a game server 3. Continue with the service call to contact a fake game server I know this could be done with a pair of tasks, the second one activated by the action in Step 2. I'm curious to see if you could write it without the sequence spanning so much code.

@Ruckus How did you respond as a thread?

@carlw You might be touching on where co routines really shine.

Yeah. I know you can do my steps 1,2,3 a few different ways, but when the logic gets heaped on, this code can get fragmented...a task here...a task in a handler there...no real obvious control

@Ruckus knows all shortcuts and tricks no matter what technology he uses 🕶️

@carlw When you hover over a comment, there's a "Start a thread" option 3 replies Like this

@carlw About your use case, I think I would do it like this: 1. Open a View with a ListView or some other control that does

asyncItems

to get the list data where the user can select the game server and put the action into the

onUserSelect

of that list item or other control.

@edvin That's the way I usually do it too. I was wondering if you could write as a straight-forward sequence of three steps without having to move through a set of handlers.

@carlw I understand, but that would would be way more imperative, and I don't think that's something we want to move towards in a big way. I'm a little on the fence with coroutines for that exact reason. Some times it's more elegant to solve it with out existing constructs. You don't need to think about the problem as a series of steps as much.

But there must be situations where you chain a series of user interactions and remoting calls. Maybe those situations can be solved in the way we talk about here as well, but maybe not always. I'm not sure.

I've been playing with my CRM with Kotlin 1.1.1 and TornadoFX 1.7.1-SNAPSHOT. I've gone through most of the screens in there, I see nothing weird. Pretty sure we won't run into any problems with this.

@edvin I'd like to show you a little more. What I'm describing (2 steps + a popup) doesn't sound very compelling. But if the initialization is complex, I think it might be preferable to have it define the logical structure rather than the combination of handlers, particularly if there is another async player in the init like a websocket. this non-FX example describes better what I'm talking about with regard to a simple synchronous sequence becoming much more complex with Tasks. https://blogs.msdn.microsoft.com/vcblog/2016/04/04/using-c-coroutines-to-simplify-async-uwp-code/

Checking

Basically, the anti-pattern that I think we can improve on with coroutines is a sequence of nested Tasks that keeps adding Tasks into succeeded()

Oh wow.. C++ really rubs me the wrong way 🃏

@carlw I tried to come up with some examples that might be good for coroutines, like for example an order editor that needs both a customer and an order before it can be shown. But those to calls can just be performed in the same

runAsync

block, so that`s not a good option either. Reading that awful C++ mess now, maybe that will clarify things for me.

@edvin I think the key is to follow the indentation. the code is very readable with the coroutines (back to the simple sequence of steps). it's less so with the "create_task" / Task version which starts to get very nested. You're right that you can kick of a Task, go to an event handler, kick off another Task. However, this hurts readability because the sequential process is now spread all over the place. Anyway, i'm not suggesting that we need a new concept to select an item in a ListView. Maybe something good will come out of some tinkering?

Yes, we definitely need to play with this. What I meant about the two remoting calls is that you can just do them in the same

runAsync

block, but then you need to return a touple, so it wouldn't be as nice, and it would be awful when you need to fetch more than two things. This is a pretty good use case for coroutines already.

I'm not sure how we'd interface with task though. This is what we need to play with.

i think it's going to be an alternative to Task

Maybe you're right.. Maybe it doesn't fit with Task at all.

@carlw @edvin - I think this is a really valuable issue to address

@gtnarg Absolutely. We need to figure out exactly what it should solve though. Should it be an alternative to

runAsync

when you don't need

Task

interaction for example?

should the question also not be "is there something in the coroutines that we are missing in TornadoFX?"

Yeah, what problem are we trying to solve exactly? I mentioned one use case where it would be nice though. That might even be enough to start working on it.

What was that use case?

Hang on Ron, Pair Programming Day ™️

that should be banned