Is the Effect type really needed?

[sroddy]

Hello,
first of all I have to thank you for the effort. I was going to start an exploration on this very same topic before being able to find your repo.
The porting looks really clean and it's very very similar to what I had in mind :)

I have a little doubt related to your current implementation: what is the reasoning behind the need of the Effect type? Wasn't it possible to just use a straight Flow and get rid of it?

From what I understood, in Swift it was basically created because of a language limitation, but I'm not sure that the same limitation applies to Kotlin too.

Thanks a lot

[gyulavoros]

Hey @sroddy, thank you for reaching out and for the kind words!

You are absolutely right; in Swift, it is required out of necessity. Here, when I implemented the Effect type, I was wondering about this as well and had the following train of thought:

• most of the kotlinx.coroutines APIs are marked as XZY interface is not stable for inheritance in 3rd party libraries ..., so I ruled out subclassing
• as of now, probably we could implement all the functionality as extension functions on Flow directly, but in the long run, we may have more control over a custom type
• right now, the implementation is tightly coupled to kotlinx.coroutines, but with time, this could be an implementation detail, and we can provide a plugin system as the runtime to execute effects (e.g., RxJava, Reactor, virtual threads, etc.)

With that said, I'm fully open to suggestions, as things are experimental and there's no stable release, so we can still change the APIs.