Re: [boost] [MSM] Comparison with ad-hoc FSM implementation

Subject: Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2009-12-09 09:18:35

Christophe Henry wrote:
> Hi Phil,
> 
>> switch ((state<<8) | event) {
>>  case (Stopped<<8)|play:       start_playback(); state=Playing; break;
>>  case (Stopped<<8)|open_close: open_drawer();    state=Open;    break;
>> etc. etc.
> 
> 
>> The greatest advantage of this ad-hoc style is that it is readable
>> by anyone who has even the most basic understanding of C++ without
>> the need to learn a new library, and its exact behaviour is immediately
>> evident.  It is also likely to compile and run quickly.

I used to do that, but found someone reordered the state assignment 
before the function calls, and one of the functions was dependent on the 
value of state. Having a truly declarative State Transition Table 
disallows accidentally changing the above procedural statements 
sequencing. It also helps reinforce the FSM mindset, which showed the 
aforementioned function should have been represented as additional 
states and events.

As to whether the above is "immediately evident" it is not so evident to 
me. I need to interpret a very generic "switch" and "enum" facilities 
and intuit the semantics from the variable names that it's implementing 
an STT. Whereas in MSM and it's predecessor the TMP book's STT example 
declare a type ala:

   struct transition_table : boost::mpl::vector41 ...

To me this is much more evident, and is analogous to using std::copy, or 
std::accumulate instead of a for-loop... the 1st word of the statement 
tells me the full semantics of whats to come.

[snip]

> - events containing data. In your case, you are more or less forced to
> choose between the O(1) (which you did) and forgo event data or the
> O(n) (chosen by Rhapsody) at a speed cost. Metaprogramming techniques
> allow us a O(1) with event data.

This was an important one for me in handling UI selection with an FSM 
that replaced lots of client code with a single shared state machine 
processing events such as pressed_item, shift_pressed_item, over_item, 
release_item... Since these are types, they can have multiple 
constructors to handle specific needs and be polymorphic for additional 
design expression. I've also found that using enums in the OP's fashion 
quickly degrades into a redundant pseudo-type-system increasing 
cognitive and maintenance overhead while decreasing type safety.

[snip]

> Of course, like always, developers use only 20% of all UML features.
> But it's never the same 20%, so what you need depends on your "coding"
> style.

Exactly!!! So now we'll have a standard place(or two, including the 
StateChart library) where all developers can look for documentation on 
how to address FSM issues in an accepted and consistent way.

[snip]

Jeff