Re: [boost] New library in Vault: Msm (Meta State Machine)

Subject: Re: [boost] New library in Vault: Msm (Meta State Machine)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2008-10-17 12:15:48

Hi Andreas,

First of all, thank you for taking the time for such a lengthy answer.

> So IIUC then you think that transitions crossing state boundaries are bad
> practice and should be avoided at all costs?

Yes I do (not at any cost of course). Not only because it looks to me like a
goto, but also because I feel it is a breach of encapsulation, for example,
in the diagram, the "alarm-beeps" state is showing its implementation. It is
also unclear to me if the entry method of "alarm-beeps" will be called.

> OTOH, the transition triggered by x can only be
> made non-state-boundary-crossing by introducing a guard, which is IMO less

> concise than allowing for the transition as shown in the chart.

This is a matter of taste. I personally prefer this as it reduces the
coupling of the system.

> As an aside, I don't see much of a connection of state-boundary crossing
> transitions with goto. Given your code in the C() function, any transition

> could/would be implemented with goto?

What I mean is that if you imagined a transition processing as a function
call, code using entry pseudo-states would in effect look like the code in
the C() function where you could skip the initialization work done in the
entry of C and B. It was not meant as real code but as illustration. Sorry
if I didn't manage to make my point clear.

> Given the examples in the Harel paper and the fact that the UML standard
> expressly allows them, I would encourage you to support them.

So does C++ support goto and breaching encapsulation, and it still doesn't
make them desirable to me. Now, I thankfully take the feedback, and if
confirmed, I will add the entry/exit states.

> for the same reasons I don't detect value in seeing a composite state as a
fully
> fledged state machine (as your framework seems to do). I know that the UML

> has so-called submachines but they are really just simple composite states

> with entry and exit points thrown in.

I admit the UML standard is not too clear in its description of submachines
but states the goal clearly (UML Superstructure specification v2.1.2 p549),
as: "Submachine state is a decomposition mechanism that allows factoring of
common behaviors and their reuse".

And this is a main design point for Msm. Submachines in Msm intend to be
reusable blocks, like classes and functions. They have entry points (entry
conditions and initial states), can be defined in different files and reused
in different state machines. What defines a FSM with Msm is its transition
table, not the inside of submachines. Submachines can be reused in different
main state machines and the link between all is the transition table. Now,
if the outside world knows the inside of the submachine, which would in
turn  know about the outside world, I'm afraid it'll be hard for submachines
to be reused.

However, your example and your point of view are very interesting as they
force me to offer a better solution than the one I have (which would be in
the init state to forward the events manually). Would the following
compromise solution be acceptable to you? Like with deferred events, it
would be possible to define automatic forwarding in a state (like the
initial one) like this:

typedef mpl::vector<T,T1,T2> forward_events;

and at the end of the transition, these events would be resent (to the
corresponding beep state as defined in the transition table). Like this, it
is guaranteed that the entry methods are called, thus ensuring safe
initialization and we would come close to an entry pseudostate. To explain
better, I uploaded an image into the Vault.

Regards and thank you for your time!
Christophe