Its interesting that people here are talking about the UI-thread coding issue but this in my view is already a solved problem in Scala as mentioned earlier, i.e. you can make your own ExecutionContext that points to the Swing event dispatch thread
object SwingExecutionContext {
val executionContext: ExecutionContext = ExecutionContext.fromExecutor(new Executor {
def execute(command: Runnable): Unit = SwingUtilities invokeLater command
})
}
And then using standard Future composition you can just do this
for {
_ <- something
_ <- something
_ <- something
_ <- Future.successful(()).flatMap { _ =>
for {
_ <- showGui()
_ <- setProgress()
} yield ()
}(SwingExecutionContext.executionContext)
} yield ()
The Future.successful is a bit weird but its written that way because you are not passing any data from another Future to render into the UI thread, i.e. something like this is more realistic
for {
_ <- something
_ <- something
_ <- something
_ <- getCurrentProgress().flatMap { progress =>
for {
_ <- showGui()
_ <- setProgress(progress + 10)
} yield ()
}(SwingExecutionContext.executionContext)
} yield ()
Other IO types like Task/IO can also do this. The example shows how you can invoke computations outside of the main UI/event dispatch thread (typically with Future this is a ForkJoinPool and in the above example it would use whatever implicit ExecutionContext you have in scope) and then you can explicitly provide your own ExecutionCOntext if you only want to execute something onto the UI thread since you don’t want to overload it.
).
That’s probably too much. Writing to mutable state? Probably not. Performing a network call? Probably yes. Maybe tracking non-local computation would be a good, precise term?