Support for Hierarchical State Machine?

[Bouke]

Hi @inamiy, I really like your take on state machines in Swift. I'm now running into an issue in which support for a Hierarchical State Machine would benefit the architectural design. For example, I have three states: A, B and C. A and B are two variants; and it is possible to go from either A or B to C. However, from C it is only possible to go to A. So I would need a handler (A, B) => C and C => A. However SwiftState doesn't allow me to create a handler (A, B) => C, so either I duplicate the handler (no good), or disregard the current state and add nil => C (but that also allows C => C, and a future D => C). As the states grow complexer, this would result in headaches; as adding yet another state would require re-evaluating all the current handlers.

[inamiy]

Hi @Bouke, thanks for your feedback.

Your situation can be solved using condition in addRoute(state:condition:).
To do that, try

machine.addRoute(nil => .StateC, condition: { transition in
    // from anywhere to .StateC at first, but restrict fromState to only A or B, using condition
    return transition.fromState == .StateA || transition.fromState == .StateB
}

For more information, please see blacklisting technique in: StateMachineTests.swift#L116-L129

[inamiy]

Oops, I forgot the handler part. Please use this instead: addRoute(state:condition:handler).

You can also do like this:

machine.addHandler(nil => .StateC) { context in
    if context.fromState != .StateA || context.fromState != .StateB { return }

    // do whatever handling you want for A => C or B => C only
    ...
}

[Bouke]

Well that's also what I meant by using the nil state. However, add another 20 states and it becomes very hard to maintain or even grasp the states of the machine by looking at the routes. For example, take the following picture of a HFSM:

source

This state machine allows to go from (Dive | Crouch) => Roll => Crouch. This is a very clear state transition.

Another solution would be to use SFSM (nested FSM), this could be modelled as 4 different state machines:

source

Or the following picture, where an UML state machine is shown. In my example case both A and B would be within s1, and the transition from s1 to s2 would equal the nil => C case in the example.

source

[inamiy]

Thank you for detailed information!
Your post gave me a good insight 😉

To achieve your (Dive | Crouch) => Roll transition (HFSM),
I added a simple helper in #9 (db73c10) as:

machine.addRoute([.Dive, .Crouch] => .Roll)

Now complex routing becomes more declarative and understandable :)

For nested FSM, please let me take some more time to dig into.

[Bouke]

Thanks for the changes, that already cleaned up some code. 👍

Being able to also specify handlers that way, would also be great. However these changes somewhat eases the burden on complex state machines; it would still be able to address so-to-speak categories. Like in the example above only define s1 -> s2 transition, without worrying about the sub-states of s1 and s2.

[inamiy]

I added a HierarchicalStateMachine feature in #10.
Please take a look and tell me your thoughts :)

[inamiy]

I will merge #10 anyway and close this issue.
If you've got any opinions, feel free to reopen.

[Bouke]

Sorry, i haven't been able to look at this thoroughly. Good to hear that you'll be merging your solution. However, would it be somehow possible to also create a HSM with static typed states, with enums?

[inamiy]

In ver 4.0.0, I refactored many codes and now states with enums are supported for hierarchical state machine.
Please see Ver 4.0.0 Release Notes and new HierarchicalMachineTests.swift for more info.