Andreas Huber <ah2003 <at> gmx.net> writes:
Darryl Green <darryl.green <at> unitab.com.au> writes:
Maybe I'm just being thick If exit actions happen after transition actions... They don't. In any transition all exit actions are executed first, then the
David Abrahams <dave <at> boost-consulting.com> writes: transition action and finally all entry actions.
Ok - make that definitely being thick and failing to rtfm :o) In hindsight, this is clearly the order one would expect for action execution but the idea that a state would "exist" until a new state was entered was too strongly ingrained, and I failed to think this through fully. It seems that this whole business of having an FSM that has meta-states in which no state exists (ok, you call them unstable states and an outer state, or possibly the FSM itself, always exists, but the outer state isn't really part of the simple state machine) is a LEM violation that just makes things complicated. I do think there is utility in having memory and resources associated with/contained by the state. However I think the current state lifetime wrt actions is wrong. To quote Bruce Douglass in Doing Hard Time - 7.3.1 Basic State Semantics ".. a state is a condition of an object during which a set of events is accepted and some actions and activities are executed, and the object can reach some set of states based on the events it accepts." If the lifetime of the state object (afaik in UML a state isn't an object at all) is to model the duration of the state, this implies that the state must exist until the transition is complete (and a new state exists). Anything else is a LEM violation. So, I now see that mapping entry/exit actions to c'tor/d'tor of the state gets one or the other of action invocation order or state duration wrong. I think that with a separation and re-ordering made, the exception handling should be less controversial, though if the previous state is destroyed before the new state is constructed, a throwing constructor will still be interesting to handle. That said, one suspects the "can't acquire resources to enter state" exception is really one which dooms at least the inner fsm, and it isn't particularly likely that the previous state could have dealt with this in any useful way. This change would also allow an action's context be to be the source state - or would there still be some problem with that? Does the context really have to be an outer state of the destination as well as the source? Oh - and I should have said somewhere earlier in all this that it is a very nice library - it really does seem very powerful, and I'm very keen to put it to real use. Regards Darryl.