Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: darryl.green_at_[hidden]
Date: 2009-12-08 01:21:19

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.