Darryl Green wrote:
A state is considered left (and hence is destructed) only after exit and transition actions have run.
That is, the previous state is destructed immediately before the new state is constructed. For nested states, all exit actions would run, followed by the transition action, followed by destruction of the states being left, followed by construction of the new state(s).
I don't see what that would buy you.
Well it buys access to the state being left from the transition action for a start.
Right, but I don't think it is justified to complicate the interface and the implementation (we'd need to add entry()/exit()) for that. As I've explained in my answer to your other post you can always move such a variables into an outer context that exists during a transition.
In addition, if the exit action isn't the destructor, and it fails, you are still in the original state. A state specific recovery action is possible, using the state's own context. The state destructor still must not fail.
A state-specific recovery function would make error handling much more difficult, as you have no idea what you need to do to bring the state machine back into a stable state. If you e.g. make a transition from such a state, it is not guaranteed that the machine is stable afterwards (see Exception handling in the tutorial).
My specific concern is the use of the extended functionality to produce states which have/build significant context that (should) only exist until a transition action deals with it. I don't see that using this state context after the exit action has run is a problem. The exit action may well have added to or modified it to make the context complete, not damaged (and in particular not destructed) it.
That's true, see above.
I'm also concerned that the current fsm destruction/exit action implementation model results in an environment where I should avoid using exit actions that have any significant external effects because I don't want/expect them to be run when/if the fsm is destructed.
Concern noted. This is actually the central disagreement between me and Dave Abrahams. If you have any real-world examples, I'd be *very* interested to see them.
Both the above concerns can be addressed by using custom reactions to implement "pre-exit" actions when/if this turns out to be necessary.
Yes. It becomes a bit cumbersome when you have multiple transitions originating at the state though.
I'll have to use the fsm library some more to see if this turns out to be the case regularly enough to make it a significant use case.
So, I now believe that the library has the necessary flexibility, and only experience will tell how much and in what direction that flexibility gets used/stretched. I'll keep you posted...
Please do! Regards, Andreas