Darryl Green wrote:
>  It seems that this whole business of having an FSM that has
>  meta-states in which no state exists (ok, you call them unstable
>  states and an outer state, or possibly the FSM itself, always exists,
>  but the outer state isn't really part of the simple state machine) is
>  a LEM violation that just makes things complicated.

What does LEM stand for?

>  I do think there is utility in having memory and resources associated
>  with/contained by the state. However I think the current state
>  lifetime wrt actions is wrong. To quote Bruce Douglass in Doing Hard
>  Time - 7.3.1 Basic State Semantics ".. a state is a condition of an
>  object during which a set of events is accepted and some actions and
>  activities are executed, and the object can reach some set of states
>  based on the events it accepts."
> 
>  If the lifetime of the state object (afaik in UML a state isn't an
>  object at all) is to model the duration of the state, this implies
>  that the state must exist until the transition is complete (and a new
>  state exists). Anything else is a LEM violation.

Sorry, I don't follow you here. The sequence of how states are left and
entered during a transition is clearly defined. Do you suggest that a state
that has been left must somehow still exist? If so, why?

>  So, I now see that mapping entry/exit actions to c'tor/d'tor of the
>  state gets one or the other of action invocation order or state
>  duration wrong. I think that with a separation and re-ordering made,
>  the exception handling should be less controversial, though if the
>  previous state is destroyed before the new state is constructed, a
>  throwing constructor will still be interesting to handle.

I don't see what that would buy you. Whether you separate state
construction/destruction from execution of entry/exit actions or not you
will still face the same logical problems (e.g. a failing exit action still
gets you in the same trouble, see http://tinyurl.com/32hhc, (Why exit
actions must not fail)).

>  That said,
>  one suspects the "can't acquire resources to enter state" exception
>  is really one which dooms at least the inner fsm,

Right, it does doom the inner FSM, but why should that be a problem?

>  and it isn't
>  particularly likely that the previous state could have dealt with
>  this in any useful way.

I often find myself needing to handle a failure that happens in a "bunch of
states", no matter where the failure actually occurs (failing entry action,
failing transition action). In such a situation I put all these states into
an outer state and implement an exception_thrown transition from the outer
state. This might seem like an arbitrary decision, but more often than not I
discover that the "bunch of states" already resides in an outer state for
logical reasons, so I just have to implement the exception_thrown transition
from there.

>  This change would also allow an action's context be to be the source
>  state - or would there still be some problem with that? Does the
>  context really have to be an outer state of the destination as well
>  as the source?

Yes, I very much believe so. The UML standard and all the code generators
I've seen define/implement it this way (i.e. all exit actions are executed
before the transition action is executed). Even if you decouple entry/exit
from state ctor/dtor, I don't think it is a good idea to have the transition
action potentially read/modify a state whose exit action has already been
called. Again, I cannot prove this, this is just my experience.

Actually, the UML standard contradicts itself in this regard. In one place
it defines that the transition action must be called before the exit
actions, and in the other place it defines that the transition action is
called after the exit actions. But I'm confident that the former is a
mistake.

>  Oh - and I should have said somewhere earlier in all this that it is
>  a very nice library - it really does seem very powerful, and I'm very
>  keen to put it to real use.

Thanks :-)

Regards,

Andreas


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