On Fri, May 28, 2004 at 12:29:01AM +0200, Andreas Huber wrote:
>  
>  
>  No, that would be wrong. UML requires that in a self-transition the exit and
>  the entry action is called (see StopWatch for an example where such a
>  transition makes sense). This is not the case for an in-state reaction.

What UML requires is not necessarily what is good for a generic FSM 
framework. The UML model is IMHO over complex and probably broken.

An example is entry and exit actions for states. It is some what oxymoronic 
that a single state should actually consist of three sub-states because
of entry and exit actions. The idea that they must be paired is particularly
strange as one of the most common uses of the concept in the networl 
protocol work that I am familar with is prior to entering the idle stae 
some initialisation work is necessary and prior to re-entering an idle 
state from an exit event we want to do some clean-up. This whole concept
is much better modeled *IMHO* by transitory states. These have the advantage
that they do not have to be paired and they allow same/self-transition 
to be a no-op which is a very common requirement.

Classical FSM's are a mapping from state/event pairs to behaviour and 
transitions. The Idea that a state should maintain its own data and 
thereby become stateful also seems to be bad modeling and against the
KISS principle.

My comments are based, so far, are based on a breif reading of the 
documentation and I plan to re-read it more carefully along with the 
implementation and provide further feedback. My gut feel is that this 
framework is too heavy weight and a one size fits all solution. Whereas
I think that an FSM equivelent to STL collections would be a better
approach.

There are two other approaches to FSM's that do not apear to be discussed in
the rationale; Herb Sutter, in an article hints at using boost::function
for FSM's and the GOF state pattern tals of using singleton, flyweight 
states which are re-enterant and therefore offer exelent MT performance.

/ikh


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