https://kotlinlang.org logo
Join Slack
Powered by
same as above, no classes needed and no side-effec...
# coroutines
p
same as above, no classes needed and no side-effects in the constructor 😄
m
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
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
Now you have one task which could be 
.start
ed multiple times 😅 How is that better than 
val task = MyTask.launchIn(scope)
?
p
it’s a Task factory!
for a single function
m
Mine is also a task factory 🤔
p
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
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
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
MyTask
is a concrete type
p
oh
hiw do you fill 
start
then?
you write one MyTask per task, no abstraction
m
yeah, that’s the starting point
val task = MyTask.launchIn(scope)
It launches & starts. Hence the 
init
p
I was already abstracting over them
ok
m
That could be added indeed 🙂
p
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
There’s no need for abstraction when you’re looking for a pattern
Like the singleton pattern 🙂
p
right, okay
pattern as in convention
dunno of any then
m
Me neither. That’s why Im brainstorming here :)
e
@Marc Knaup did you look at the 
actor
concept? Maybe you can implement an Actor.
m
@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
Maybe I'm not clear on how that works, but I thought you can send a custom message to the Actor to abandon?
m
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
Open in Slack
PreviousNext
Powered by