same as above, no classes needed and no side-effects in the constructor :smile:

# coroutines

[pakoito]

same as above, no classes needed and no side-effects in the constructor 😄

[Marc Knaup]

I do need a class though 🙂
What if you want to add some functions that affect the running task?

[Marc Knaup]

I’m also not a fan of returning () -> Unit for cancelation is that’s quite unsafe and non-descriptive, even with aliases.

[pakoito]

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!

[pakoito]

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(), ...)
      }
  }
}

[pakoito]

that’s your class wrapping a function 😄

[Marc Knaup]

Now you have one task which could be .start ed multiple times 😅

How is that better than val task = MyTask.launchIn(scope)?

[pakoito]

it’s a Task factory!

[pakoito]

for a single function

[Marc Knaup]

Mine is also a task factory 🤔

[pakoito]

I don’t know what you’re trying to achieve, I’m just moving pieces of a puzzle haha

[pakoito]

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

[Marc Knaup]

That only works if the only action you can ever perform on a task is cancelation. That’s quite inflexible.

[Marc Knaup]

I’ll write one example for that 🙂

[pakoito]

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

[Marc Knaup]

MyTask is a concrete type

[pakoito]

oh

[pakoito]

hiw do you fill start then?

[pakoito]

you write one MyTask per task, no abstraction

[Marc Knaup]

yeah, that’s the starting point

[Marc Knaup]

val task = MyTask.launchIn(scope)

It launches & starts. Hence the init

[pakoito]

I was already abstracting over them

[pakoito]

ok

[Marc Knaup]

That could be added indeed 🙂

[pakoito]

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?

[pakoito]

the question was too broad, I was just having fun making the class into an interface

[Marc Knaup]

There’s no need for abstraction when you’re looking for a pattern

[Marc Knaup]

Like the singleton pattern 🙂

[pakoito]

right, okay

[pakoito]

pattern as in convention

[pakoito]

dunno of any then

[Marc Knaup]

Me neither. That’s why Im brainstorming here :)

[Marc Knaup]

Here’s a mix:

https://gist.github.com/fluidsonic/be1cf0329ecc1994cf911beefdcb0631

[EyeCon]

@Marc Knaup did you look at the actor concept? Maybe you can implement an Actor.

[Marc Knaup]

@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.

[EyeCon]

Maybe I'm not clear on how that works, but I thought you can send a custom message to the Actor to abandon?

[Marc Knaup]

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.