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

pakoito

04/20/2020, 12:04 PM
same as above, no classes needed and no side-effects in the constructor 😄
m

Marc Knaup

04/20/2020, 12:31 PM
I do need a class though 🙂 What if you want to add some functions that affect the running task?
I’m also not a fan of returning
() -> Unit
for cancelation is that’s quite unsafe and non-descriptive, even with aliases.
p

pakoito

04/20/2020, 12:56 PM
Copy code
interface DisposeJob {
 fun cancel(): Unit
}

fun CoroutineScope.launchTask(job = Job(), f: suspend fun () -> Unit): DisposeJob {
  launch(job) { f() }
  return object: DisposeJob {
   override fun cancel() =
     job.cancel()
  }
}
sure! an interface can replace a typealias!
Copy code
interface Task {
  fun CoroutineScope.start(f: suspend fun () -> Unit): DisposeJob

  companion object {
    operator fun invoke(makeJob: () -> Job = { Job() }): Task = 
      object: Task {
        override fun CoroutineScope.start(...) = launchTask(makeJob(), ...)
      }
  }
}
that’s your class wrapping a function 😄
m

Marc Knaup

04/20/2020, 1:23 PM
Now you have one task which could be
.start
ed multiple times 😅 How is that better than
val task = MyTask.launchIn(scope)
?
p

pakoito

04/20/2020, 1:26 PM
it’s a Task factory!
for a single function
m

Marc Knaup

04/20/2020, 1:26 PM
Mine is also a task factory 🤔
p

pakoito

04/20/2020, 1:26 PM
I don’t know what you’re trying to achieve, I’m just moving pieces of a puzzle haha
my gut feeling is that what you want is to store the Jobs for cancellation, rather than a class encapsulating a single execution and delegates to those jobs
m

Marc Knaup

04/20/2020, 1:28 PM
That only works if the only action you can ever perform on a task is cancelation. That’s quite inflexible.
I’ll write one example for that 🙂
p

pakoito

04/20/2020, 1:29 PM
at some place you’re going to have a List<MyTask> so you won’t be able to access other methods or fields unless you disambiguate by type
m

Marc Knaup

04/20/2020, 1:30 PM
MyTask
is a concrete type
p

pakoito

04/20/2020, 1:30 PM
oh
hiw do you fill
start
then?
you write one MyTask per task, no abstraction
m

Marc Knaup

04/20/2020, 1:31 PM
yeah, that’s the starting point
val task = MyTask.launchIn(scope)
It launches & starts. Hence the
init
p

pakoito

04/20/2020, 1:31 PM
I was already abstracting over them
ok
m

Marc Knaup

04/20/2020, 1:31 PM
That could be added indeed 🙂
p

pakoito

04/20/2020, 1:31 PM
then you won’t have access to specialisation. So if the question is: “what is the pattern”, then there’s no pattern, you’re building your own set of operations right?
the question was too broad, I was just having fun making the class into an interface
m

Marc Knaup

04/20/2020, 1:33 PM
There’s no need for abstraction when you’re looking for a pattern
Like the singleton pattern 🙂
p

pakoito

04/20/2020, 1:33 PM
right, okay
pattern as in convention
dunno of any then
m

Marc Knaup

04/20/2020, 1:34 PM
Me neither. That’s why Im brainstorming here :)
e

EyeCon

04/20/2020, 8:57 PM
@Marc Knaup did you look at the
actor
concept? Maybe you can implement an Actor.
m

Marc Knaup

04/21/2020, 8:35 AM
@EyeCon thank you for the suggestion. It doesn’t solve the problem with cancability (is that a word?) and having an interface to the running task for calling task-specific functions.
e

EyeCon

04/21/2020, 8:50 AM
Maybe I'm not clear on how that works, but I thought you can send a custom message to the Actor to abandon?
m

Marc Knaup

04/21/2020, 8:51 AM
I don’t want to abandon it. I want a reference to the task so that I can cancel it or perform other operations on a running task which are task-dependent.
2 Views