Advantages of type-fsm
Focus on the right message
The FSM receives messages and changes state. When in a different state, it will only receive messages that are appropriate for that state. Any messages that do not belong to that state will be detected by the compiler and a warning will be issued. The compiler will also issue a warning if a certain type of message is not processed.
Top-to-bottom design for easy refactoring
In typed-fsm, messages that drive state changes are concentrated in instances of StateTransMsg, and subsequent processing functions and message generation functions depend on it. This top-down design makes it very easy to refactor. Any changes to the message definition will be passed to the corresponding processing functions and message generation functions. Therefore, when you change the definition of a message, the type system will help you find out where the state is wrong.
In the example above, the definition of ExitMotion at the beginning indicates that the state machine can exit in any state, so it should generate and process ExitMotion messages in the three states of Idle, Over, and Hover. Then I modified the definition of ExitMotion, and the new definition indicates that ExitMotion messages can only be generated and processed in the Idle state. So the compiler helped me find all the incorrect uses of ExitMotion under the new definition.
Conducive to building complex state machine systems
-
Type guarantees will not produce incorrect function calls when written
-
With the help of the type system, we can define many state processing functions and then call each other recursively with confidence.
In a complex state machine, states change and corresponding processing functions call each other. Without type support, it is easy to make incorrect calls. typed-fsm can ensure that the state changes of the calling function are correct, which almost guarantees that there will be no incorrect function calls when calling each other.
In the above example: MoveOut changes the state from Over to Idle. The corresponding processing function can only be idleHandler. If you forget to write it or write other functions, a compilation error will occur.
There is a sanity check. If you miss some items for pattern matching, the compiler will issue a warning, and there will also be a warning for invalid items.
This is a bit repetitive with the first point, but it really is a very trouble-free ability.
Some usage suggestions:
-
When defining a state machine, it is best to add a bottom state, such as the Exit state in the example above.
-
Turn on -Werror=inaccessible-code, and errors will be generated instead of warnings when you match error messages.
-
In addition to the bottom state, it is best to give each state a separate handler function, so that it is easy to call each other.
-
Handler functions boldly call each other, and the type system will keep you safe.
Finally, I would like to add one more sentence:
typed-fsm + hls = I love developing finite state machines!