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.


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