Andreas Huber <ah2003 <at> gmx.net> writes:
Darryl Green <darryl.green <at> unitab.com.au> writes:
Right. This works too. I don't really understand your objection to the transition semantics I proposed.
Sorry, I didn't justify this enough. My main concern is that changes in one part of a state machine no longer lead to compile time errors in other parts, although they probably should.
Ok. Valid criticism. The only thing that makes me uncomfortable about the compound_transition approach vs relaxed transition action is that for some very simple cases it rearranges the diagram into someting quite odd: An inner transition with action (the pre exit) that passes the event out (how do you represent *that* in UML?) and a normal transition and action. What I proposed is also unrepresentable but I would doesn't actually have a direct UML representation anyway. My reasons for favouring it are only because if Active held useful context, and hence various actions to work with this context, and if there were an added transition from Stopped out of Active into some state Foo, which needed to use the Active context in the transition action, I'd be inclined to try to write just that. The transformation to a compound_transition out of Active to Foo, That is, the programmer is no longer forced to
explicitly say what he means when he makes a certain type of change. For example, suppose there is an action associated with the transition between Running and Stopped. If you now move the Stopped state out of Active then said transition action is still executed before the Active exit action (i.e. the programmer is not forced to consider all the side effects of his change). I see your point that this would lead to problems only rarely, but it *can* happen. In fact, in the field where I used to employ state machines (controlling machinery) this could be a problem more than rarely because actions more often than not have global side effects (they change the state of hardware machine parts).
Point taken - but then I'm sure you take great care. Even without my modification, you still had to think carefully about the consequences of that small change - exiting Active might well have global side effects too. If you look at exit and any other Active actions/member functions that make up the transition you will get it right. If you don't...
Sure, the error very clearly lies with the programmer who failed to RTFM but he does have a point when he says "Ummm, UML mandates that all exit actions are always called before the transition action and I thought that boost::fsm claims to stick to UML, right?"
So you think the pprogrammer will consider the consequences of the exit, but will still expect the transition action to be called after its context is exited? The next question is - when it does fail to compile will the programmer find it easy/obvious to replace the Running->Stopped transition with an Active->Stopped compound_transition with the original action moved to be a the pre-exit action?
Moreover, I think it is much more readable this way (although we should probably find a better name for compound_transition) and I hope that other people will agree.
I do see some merit in your proposal, I just think it is much too early to make such a change with just you and me considering the implications (once
I've said my piece here already, and sort of re-said it in my last question above... the
change is made we cannot go back without breaking existing code).
Like I said - it is easy (I think?) to make it an option. It might be useful to acquire experience with how well these alternate approaches work in practice.
I'm done on this one, but I would like to hear other comments
Sorry for carrying this on when I said I was stopping :-) Regards Darryl.