Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-07 10:13:58

Hi Darryl,

>I agree with this. However, I have yet to come completely to terms with
>how best to use msm. I am beginning to think, in trying to use it, that
>it would be better to separate the state transition table definition as
>much as possible from what, in an msm world, are more like semantic
>actions. This is very different from the more oo modeling approach of
>statechart. I'm not sure the statechart isn't better at expressing fsms
>that "emerge" out of overall application/system design in an all
>encompassing oo design uml world, and msm better at expressing more self
>contained "islands" of fsm in an app

As far as I can tell, state machines and OO modeling are completely
orthogonal concepts. An OO implementation doesn't mean that FSMs are
an OO concept.
Can you precise your point with a concrete example?

>I'm far from an expert with
>spirit, but I think there are many concepts that could be borrowed from
>it to make msm better able to be used to define a fsm that can be bound
>to separate objects to implement behavior and exend its use beyond these
>islands.

Again, can you help us with more concrete examples?

>Basically, it needs to be easier to take a 1 TU transition table
>integrate it into to a bigger multi TU system

What would it concretely bring? Compile-time improvements not really, so?

>actions - the functor approach is good - though it needs a bit more
>development to make it easier to bind to actions that are not explicitly
>designed for use as msm state machine actions.

What would it bring? You can simply ignore the functor arguments if
you don't need them. A closer look at eUML will however show you that
having your source/target states at hand in a transition handling can
be pretty useful.

>states - I don't really understand what an instance of a state is in msm
>- it doesn't model anything meaningful to me.

Where do you suggest putting the entry/exit actions and the flags? All
in one big fat react function with lesser code reuse possibilites? And
all the state data inside a fsm?
Why giving up reuse of states?

>This is unlike statechart,
>where the idea of object instantiation as state is genuinely useful -
>sometimes, and where it is the state that "reacts" to an event

In UML, it is a state machine which reacts to an event, not a state.
Statechart != UML (the same applies to MSM).
Furthermore, "unlike Statechart" isn't a valid argument, is it?
Making MSM look like Statechart is not the goal (besides, David would
make us another round ;-) Just kidding, David)
Could you please develop your point a little?

>Should msm drop state objects altogether and simply have some sort of context /
>current state object? Arguably it already has one in the form of the fsm
>object - though that is a bigger concept than context.

I disagree. I see no gain doing this. Just more confusing, tightly
coupled, unreusable state machines.

>Michael Caisse has already pointed out that there is something slightly odd about the
>current state being represented as a scalar in a model that has objects
>as states

Did we read the same post? I didn't read all this in any of his posts.

>I haven't spent much time thinking about this

I also have this feeling, to be frank.

If I understand, what you want is a MSM looking like Statechart. What
for? I think a few concrete points would help us all.
Of course, MSM could easily support a Statechart-like frontend, but
nobody required this so far. I had the opposite feeling, that most
people welcomed the lesser coupling offered by MSM. Or am I getting it
wrong?

Christophe