Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-19 14:06:24

Hello Alexander,

Tuesday, December 19, 2006, 12:46:01 AM, you wrote:

> Andrey Semashev wrote:
>> Thanks for the article. It dropped me a thought of a way of improving my
>> automatic transitions support in runtime.
> You're welcome!  What idea, BTW?

Well, currently there's a two-phase transition lookup: a compile-time
search of a transition rule in the map (with "is_applicable" MPL
predicate) and a runtime check wether the statically found rule will
actually trigger the transition (a static function "is_allowed"). You
might have seen it in the library docs.

This "is_allowed" is implemented in each transition rule. It takes an
event and returns true if the transition should be performed or false
otherwise. So it only allows or denies the library to perform the
transition.

The idea is to pass a reference to the current state to the function
and let it switch the state itself (due to this change of semantic I
will have to change its name to somewhat like "transit"). Although
this exposes states' implementation to transitions, this would add
more flexibility.

The dark side of the change is that I'll probably have to add another
layer of dispatch of the event (it will cost an additional function
call via a function pointer in runtime) and probably some increase of
compilation time.

>> Although, I still don't catch the point of creating/destroying state
>> objects during transitions. This can even be inconvenient if a state
>> is intended to be visited more than once.
> It's easy to draw a graph by analyzing signatures of transitions. It's
> not possible with switch_to<State>() because these calls can appear
> anywhere in the on_process body. This is very important use case, IMO.

Yes, I agree. That is why there is a support for transition maps in my
implementation that I've spoken of above. Although in many cases
the switch_to approach is more simple and flexible.

> You can always define a state with a pointer to the state's data. This
> is usually a good distinction especially if states hierarchy is used
> to model inner and outer states. In this case, states hierarchy in often
> not related to state's data hierarchy.

A pointer to the state's data doesn't help if the state is actually
destroyed when being left (the pointer is freed and the data is lost).
And storing such pointer in a place somewhere out of the state (i.e.
in a base state, a state machine or its some common storage like
virtual bases in my implementation) means that data is exposed
and is no longer specific to the state. IMO, this breaks the natural
state encapsulation that is one of the main ideas of FSM concept.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]