I need some advice: I have done a project that pro...

# coroutines

[corneil]

I need some advice:
I have done a project that provides an FSM implementation and a DSL for defining the FSM. As part of the DSL you can provide lambdas for the actions the FSM will invoke.

Will it be best to provide the user with a choice up front as to whether all actions will be suspend functions or is there an elegant way that I may not have considered to have a lambda that may or may not be a suspend function and the decision on how to use is is made later?

The primary repo can be found here: https://github.com/open-jumpco/kfsm

[Erik]

Interesting question, I'm interested in this too.

One trivial naive solution would be to provide two different interfaces with the same functions, but one is a coroutine version in which all functions have the suspend modifier. This would require you to maintain two practically identical versions of the interface from now on. I'm assuming that this is what your question is about?

[corneil]

Yes, it seems that it is my only option is to try and isolate that portion as far as possible and then have 2 hierarchies.
The design has builder classes for the DSL a definition class and an instance class and all are affected to some extent.

[Casey Brooks]

I think the nature of an FSM would make sense to be all suspend functions, especially if those suspending functions are lambdas (which the user doesn’t necessarily even need to know is suspending). Coroutines are very cheap and so there’s not really a performance penalty, and in the case that a particular lambda doesn’t call any other suspending functions, the compiler will optimize it even further to be little different from a non-suspending function

[corneil]

I am concerned about performance and I don't want to force consumers of the FSM to have to do anything extra because of suspending functions.

[Casey Brooks]

Then I think the only other option is to to maintain two interface hierarchies. The kotlin stdlib does this with sequences and collections (I think) using code generation, so that might be an option. Setting up a gradle task to generate both suspending and non-suspending versions of the API. Or else having some kind of linting task to verify each function in the public API has both suspending and non-suspending versions

[corneil]

It is only a part of the total hierarchy anyway. So I think it won't be too much work.

[Luis Munoz]

@corneil interesting project, what is your use case for that FSM project?

[corneil]

When ever you do composite UI components you find yourself needing state management. Invariably it ends up as pieces of logic spread all over.