Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-08 05:59:56

Hi Darryl,

If you don't mind, I'll start by answering the last question, it'll
make the rest of the discussion easier.

>Now I'm confused. Are you:
>
>a) Convinced the suggestion is without merit?

No. After reading your last mail, I see a bit better, though I'm not
sure I can follow all of it.

>b) Waiting for a concrete example?

Yes! Exactly.

>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)?

No.

Sorry if I gave you the feeling the correct answer was a) or b).
I don't mind criticism, any of it, justified or not, as long as it
doesn't stay vague and instead goes to concrete, argumented points.
Vague negative comments bring little to the review and contribute to
giving an incomfortable feeling to all participants.
Constructive remarks are, on the other side, highly welcome! That's
reason #1 for a review.
I sometimes, like yesterday, take part in several parallel
discussions, so I have little time left for remarks I cannot start
anything with. Sorry about it, it's the negative side of the review.
I'd be thankful if potentially useful but vague ideas were kept for a
more quiet time.

So now, to the concrete parts of your remarks.

>I genuinely don't see why msm needs to instantiate state objects it owns at all.

If this is the point, then it is a solvable problem. Clearly, it
doesn't strictly need. It's just a feature, which is in some contexts
very useful.
The main one is to be able to save some data in the states. This data
can then be generically accessed by the generic functors, thus
increasing reuse and encouraging clean code. The functor front-end
will be your friend in this case. The same with eUML, but it doesn't
have to be eUML.

The second reason would be entry/exit:

>I suggest spelling them enter<state>(machine) and exit<state>(machine)
> or machine.enter<state>() and machine.exit<state>().

Of course, this would be a solution. It's actually an interesting one,
and if you don't mind, we'll keep for later (see below). Do we agree
that it makes the machine slightly less readable?

The 3rd reason is state reuse. This brings us to:
>What does reuse of a state in msm mean?

Interesting question, which is sadly ignored by many fsm frameworks. A
case would be when you want to avoid doing the same case again and
again. You could then define a state hierarchy, even (gulps) OO-like
for this (or better some template policy magic). For example, I
personally often add some logging in debug mode, so that I know what
happened in my system. The visitor is another good example of it. I
hope that after having a look at it, you'll see the interest you can
gain from it.

You might have easily missed another case in the doc. If you have a
look at iPodSearch and iPodSearchEuml, you'll see where I want to go
next. To states which implement STL algorithms. You will then be able
to write complex algorithms by simply moving some predefined states on
a diagram. I plan to call it the STL (State Template Library ;-) ).
While this is for the future, I'll need independent, reusable states
for it.

>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.

I see. Then I probably misunderstood your point.

> Can you perhaps explain why flags are needed?

Sure. If you look at the statechart doc, you'll see some state_cast. I
personally find it not beautiful in my code. It's also hard to
maintain when your fsm structure changes. Flags are faster, require no
rtti, are more model-oriented as states define themselves their
"property" and makes user code easier/smaller to read. It's even
supported by eUML for better model-orientation.

I wanted to handle the entry/exit discussion separately. Hopefully I
managed to convince you why states are useful and their instanciation
brings some advantages.
Of course, there is a price to pay, though a small one (if without
data, 1 byte/state). This is in most cases not a huge cost.

I agree there are cases where the price is still too expensive. I also
agree, that the one current MSM back-end is not a solution for all
problems, otherwise I would have written in stone that there is one
backend and we'd be done. The MSM backend is a fully optimized
machine, trying to pack as many features as possible at the lowest
possible cost. There are however cases, where one would be ready to
give up some features like state reuse and generic functors in
exchange for reduced costs. For such cases, there is room for a
mini-MSM backend (name from Barend Gehrels ;-) ). And in this case,
your entry/exit solution appears a viable, interesting one for which I
am thankful.

When preparing the review, I had several possibilities:
- make the current MSM backend, with lots of features, thus proving
that the approach of the MPL book was a great one.
- make a reduced, smaller cost version, with the certainty of being
criticized for not having enough features (see review from FSM) and
rending a disservice to the book.
- make a 3rd one, more dynamic, which I want to do since a while.
- make no review until all possible back-ends are done and make
everybody wait at least one more year.

Do we agree that solution 1 seems the more logical?

I hope we managed to find a common ground and that a fruitful
discussion can take place.

Christophe