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

Subject: Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-12-14 10:59:50

Christophe Henry wrote:

> I just added in the sandbox
> (msm/libs/msm/doc) a BoostCon09 subdirectory.

[ Does anyone know if the Boost svn / web server can be tweaked to show 
a directory listing when I visit 
http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/BoostCon09/ 
with a web browser?  Currently I just see a blank page.  I can see the 
contents only using svn ls.  My own apache+svn server does show 
directory listings, so presumably it is down to a config setting 
somewhere. ]

>>One interesting feature is that there are several buttons that have
>>different actions associated with short and long presses.  So I can
>>imagine per-button state machines that do something like:
>>
>>  UP  --pressed-->  DOWN  --timeout-->  LONG_DOWN
>>      <--released----                       |
>>      <---------------------released--------+
>>
>>These could feed events like left_button_short_press,
>>right_button_long_release etc into a main state machine.
>>
>>Can you outline how you would implement this in MSM?
>
> I implemented it exactly as you described.

Well maybe not "exactly"....

>>I can see how you
>>could store the button identifier as event state and send e.g.
>>short_press(left_button) to the main state machine, but this would then
>>need transition rules using guards to test the button id.  (I don't
>>think this is an application for a sub state machine because each
>>button's machine runs concurrently, right?)
>
> I didn't generalize like you suggested.

> I simply added more regions and
> each button is handled in one of them. It is not such a big repetition
> because the south button has its own handling anyway.

It looks to me as if your implementation has ignored the left button 
(previous track / rewind) entirely, right?.  If you had implemented it 
you would need to do so by copying and pasting the code for the right 
button, which already shares nothing with the code for the other 
buttons.  I feel that I have to mention this after your earlier 
complaints about how anyone maintaining my code would have to resort to 
copy and paste and how this would inevitably lead to errors: it now 
looks to me as if MSM is in fact more reliant on copy-and-paste, not less.

> The interesting and complex part is not so much the button handling,
> which could be done with an ad-hoc solution too, but the separation of
> tasks between the regions. One handles the hold button and stops all
> processing using an interrupt state, some handle the buttons, and
> others are simply here to give to an hardware event (like using the
> middle button) a different meaning according to the state where the
> state machine is. For example, CheckMiddleButton is doing just this.
> Only one state. All regions are small, and each handles a very
> specific part of the problem. See it as a sort of "divide and conquer"
> ;-)

Divide-and-conquer can be applied to most/all design approaches.  It is 
not unique to MSM.  Personally I do not find your code particularly 
easy to follow, but that may be due to my limited knowledge of UML terminology.

Regards,  Phil.