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've said my piece here already, and sort of re-said it in my last question 
above...

>  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.

>  
>  > 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost