Hi Christophe,
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 don't consider FSMs an OO concept. That wasn't at all what I meant to suggest. I did mean to say that Statechart looks more like an extension of the typical (OO) GOF state pattern than msm does. I seem to have said (reading ahead) something here that has offended you or implied that this makes msm less useful than statechart. That was not my intent. In fact I think that msm's separation of concerns is a good thing (in some usage at least) but that I don't think it is taken quite far enough or made as easy to use as it could be. I genuinely don't see why msm needs to instantiate state objects it owns at all. I really only intended the OO aspect of this as background to what comes next, which is intended to be an anti-oo suggestion, relying heavily on tagged dispatch or similar to separate the objects implementing behavior from the fsm....
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?
Not right now, no. What I'm reporting (and I agree, you can't be expected to "fix" anything based only on my vague input) is that I am finding it harder to "attach" an MSM machine to classes that model something largely unrelated to the fsm states and transitions, but that needs to be driven from these states and transitions, than I find doing something similar to be when writing/using a parser in Spirit. I haven't had the time to sit down and analyse just why this is so, and it may be that euml addresses this (I haven't tried it because I was concentrating on trying to use msm for something of comparable size to some of the real uses I have had for fsms).
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?
Concretely it would allow me to logically attach any number of big lumpy rarely or at least rarely contemporaneously changing bits of code to the fsm without having to recompile the when modifying the fsm... I have found that I can build realistically sized fsm transition tables using msm and could probably live with the 1 TU limit. I was going to post spearately when I had something more concrete done, but I may not have time so here goes: I haven't got more than 1/4 of the way through LAPD - about 50 transitions, due to lack of time either for the grunt translation from spec work or for properly solving some of the inevitable (not msm specific) implementation of concrete as opposed to abstract/specification fsms. Consider me convinced re transition table scalability and general usefulness, but still trying to figure out the best way to use this tool.
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.
I did not mean to remove functionality from the interface. I should probably not have used the word actions here. The functor actions (as I said) are a good idea - what I was asking for was some library support for making such actions that are adapters for "external" implementation of actions. If you are saying euml is the tool for that I'm ok with that and will play with it some more. My concern is though, that I won't be able to use if for realistic machines.
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
I suggest spelling them enter<state>(machine) and exit<state>(machine) or machine.enter<state>() and machine.exit<state>().
and the flags?
Flags are a static (compile time) construct only? No need to instantiate a state object/instance to use them. (aside) I'm not sure I buy the need for the flags concept to be part of the model at all, or that the state "knows" which flags it should set (rather than a predicate outside of the states knowing which states match). Can you perhaps explain why flags are needed?
in one big fat react function with lesser code reuse possibilities? And
No. For the record, in my opinion, the single the worst feature of statechart is the necessity to use custom reactions to implement some fsm constructs. This was a subject of much discussion during the Statechart (FSM) review iirc.
all the state data inside a fsm?
Precisely the opposite. What is "state data" and why should it be owned by the FSM at all? This is what I was (obviously not very clearly) alluding to at the start of the post. When using Statechart one makes (where it fits) the object being modeled a state (possibly with a number of empty substates) and gains the advantage of state transition based RAII for such objects/states. This model remains the only one where state as object has ever struct me as being any more than an artifact of an OO design of an FSM in an OO language. MSM should surely justify that first M by avoiding unnecessary object instantiation? I don't see that it is necessary to model an FSM but maybe UML disagrees with me on this. I don't claim to be a UML statechart expert although I've used FSMs across a number of domains it has never been in a strict UML MDD environment.
Why giving up reuse of states?
I want to reuse objects, that are not states at all, more extensively than as states in fsms. What does reuse of a state in msm mean? If the state happens to be a state machine itself (ie it is composite), I can see that it can be reused. What else?
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).
Yes. Precisely. I was saying how Statechart (not UML) behaved and why this was useful. I think msm can and should do something similarly useful, but different, and which doesn't require a state object to be instantiated, ever.
Furthermore, "unlike Statechart" isn't a valid argument, is it?
No it isn't. And I didn't make that argument. I stated a fact - msm is not like statechart. We agree on that. We (might) disagree on exactly which of the possibly infinite number of "not like statechart" fsm models msm should provide, but I'm trying to have a discussion, not a war, so I don't see that as bad.
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?
Hopefully I have.
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.
Can you explain this a bit more? I haven't looked "under the covers". The original simple mpl transition table was quite enough fsm metaprogramming for me to get my head around so I didn't think it likely that a look would help... Am I missing some fundamental need for the state to be instantiated or some other problem?
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'm sorry - I shouldn't have trusted my memory of names... It was actually a post by Barend Gehrels.
template <class Machine, class Event> void no_transition(Event const& e, Machine&, int state) { std::cout << "no transition from state " << state << " on event " << typeid(e).name() << std::endl; }
All my states are structs. Why is the state an integer here? How can I (humanly or with MSM) translate that state to one of the states defined?
I don't know what you mean by "all this", it wasn't a major point, just the implication at least that the state itself isn't important in looking up transitions.
I haven't spent much time thinking about this
I also have this feeling, to be frank.
:/ To quote the rest of that sentence:
I haven't spent much time thinking about this, but I feel it is this machine/context concept that needs work to make extending the fsm easier.
Now I'm confused. Are you: a) Convinced the suggestion is without merit? b) Waiting for a concrete example? c) Convinced I'm an idiot that can't figure out how to use msm effectively (in which case, consider this a request for better docs)? Any or all answers may be correct...
If I understand, what you want is a MSM looking like Statechart.
No. I'd just use statechart if that was what I wanted.