Darryl Green wrote:
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.
You can't express it in UML, but it is a very natural thing to do. It is equivalent to overriding a virtual function in a derived class and have the implementation call the base class function before returning. Everybody uses this pattern in OO programming and I can't fathom why UML doesn't allow it. Probably an oversight.
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,
I guess you wanted to add something more here but I think I got what you mean.
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?
I guess that he's more aware of the exit (it is directly visible in the diagram). But, yeah, that's just a lot of guessing.
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?
Good point.
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 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.
Ok, convinced. I need to check how much work this is and whether there are any side effects but I don't see much of a problem at the moment. What would you say about BOOST_FSM_RELAX_TRANSITION_CONTEXT? It's a little long, do you have a better idea? Hope you can live with a global switch instead of a per-machine policy. Regards, Andreas P.S. I was away over the weekend, I'll answer the other posts on Monday.