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