From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-06-06 18:05:34
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
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
>> 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?
>> 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.
P.S. I was away over the weekend, I'll answer the other posts on Monday.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk