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