Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-14 17:35:43

Hi Darryl,

>Your responses come across as though you feel you are under attack.
>Please accept that is not my intent

I'm sorry if I gave this impression. While I was unsure what were your
concerns at the beginning, I now appreciate a lot your contribution!
You'll probably recognize your suggestions in the next versions :)

>I see these as incredibly closely related in a C++ FSM model. This is
>because, in my experience, the actions done in entry and exit actions
>are resource management-like, very similar to the role of constructors
>and destructors (or more generally scope entry/exit). I had intuited
>that the rational for including entry/exit actions in fsm notations was
>to model that scope concept.

Actually, my take on the use of entry and exit was not scope
entry/exit but rather a way to factorize behaviour out of the
transition.

So, to sum up our discussion:
- I agree that using entry/exit for RAII sounds interesting.
- paying 1 byte/state even if you don't need them is almost not
visible on the performance level but I agree that it's still feeling
not right.
- on_entry and on_exit have in my opinion, compared to constructor and
destructor, the advantage of flexibility (such as getting the event or
fsm or the ability to throw).
- while you would prefer to have no states, using them for tag
dispatching still looks interesting to you.
- I'm positive persisting data in states favors reuse in another fsm
context. I hope to bring later some reusable state concept to prove
this point.

This pretty much sums up our discussion, right? We had a rocky start
(due to my misunderstanding) but I understand this is the where we now
are.
I think that it's possible to have all this at the same time,
constructor/destructor and entry/exit, persistent states and
non-persistent, maybe in the same state machine.
I can imagine a few possible solutions but need to think more about them.
I'm pretty sure that it's possible to have at least non-persistent
states (using no memory) while being still compatible with the
front-ends (who require a source/target state).

So, I thank you for the interesting discussion which delivered
valuable points. I'll be happy to continue the discussion as soon as I
can offer a solution.

Christophe