< thanh> what is the goal you re trying to achieve kotlinlang #functional

Sadly there is not a lot of info on this 😞 but expanding on the small example from Cats you should be able to figure out the rest. If you need any help or are interested in updating that branch I’d love to help 🙂

thanh

10/08/2019, 10:24 AM

that's very kind of you. I'll check it as well as read the link you gave.

I'm interested on updating that branch

🎉 1

corneil

10/21/2019, 1:26 PM

You could take a look at a project I did to provide an FSM implementation with a DSL to simplify configuration: https://github.com/open-jumpco/kfsm/

thanh

10/21/2019, 1:59 PM

Nice library @corneil, but I need a more safe statemachine library (compiler level). Like if the door is closed, you cannot close it again.

corneil

10/21/2019, 2:00 PM

The statemachine would take care of all the state management. What is your use-case?

KFSM will throw exception when you send an event for which there is no matching transition.

So if you define:

Copy code

state(OPENED) {
    whenEvent(CLOSE to CLOSED) {
    }
}
state(CLOSED) {
    whenEvent(OPEN to OPENED) {
    }
}

In this case a CLOSE event when state is CLOSED will cause an exception.

thanh

10/21/2019, 2:45 PM

I understood that, but I want to prevent sending CLOSE event when the door is closed. Which is described here: https://typelevel.org/cats/datatypes/state.html#changing-states

arrow 1

corneil

10/21/2019, 2:53 PM

I've always viewed a state machine like a box with buttons. Sometimes the buttons do something, other times they do nothing and other times they cause an alarm. With KFSM you can even ask the state machine which events are allowed in current state or for given state so that you can enable/disable buttons/controls.

I can see a need for State management like in Cats. KFSM was designed for the cases where a UI or service endpoint has to handle events. In the case of the service the FSM is initialised with previously persisted state and then event(s) are sent.

👍 1

2 Views