Re: [boost] Meta State Machine (MSM) review

Subject: Re: [boost] Meta State Machine (MSM) review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-11 07:11:41

Hi Barend,

Sorry that I didn't have time to address earlier the questions in your review.

>I would like to see a connection with Boost.Graph (I mean, see it in an
>example or so, not within the kernel), to see what I'm doing with all
>those transitions; I asked this on the list and this is possible, good.

It is a good point and I'll try to provide this, at least for simple
state machines.

>1) the struct "Row" is written with a capital, this is unusual within
>Boost. Words with a capital are normally template parameters. I
>understand why it is done (there was already a row without a capital in
>Msm 1.1), but I think it could have been solved differently (for
>example: "transition", or if that is too long "tr" which could stand for
>transition row or table row). I don't like to see Row where I expect to
>see a normal classname.

Conventions are always hard to define. I usually try to follow the
following convention:
- rows are usually not capitalized (a_row, g_row...)
- except the row working with functors, like Row
- eUML functors are also capitalized and finish with an underscore.
- eUML functions are not capitalized and finish with an underscore.
This tries to match the phoenix syntax.

This allows differentiation between functors/non functors. I found
this system practical but would not mind changing it if required.

>The capitals are also used in the documentation and samples (struct
>Empty) but there I've less problems with it. Maybe use of Capitals for
>states is a state machine convention

Yes, it is a common habit in UML to capitalize state names (though I
am not aware of any written rules).

>I noticed different conventions in
>the source files. Many template parameters are completely capitalized. I
>had done the same thing, earlier, but was hinted that this is unusual as
>well. Just a matter of style (as long as library users normally don't
>see it, it is less important)

Yes, while the user doesn't see it, it is not very beautiful so I'll
change this.

>2) the class state_machine is quite long (in lines of code), containing
>several sub-structs which maybe (don't know) could be moved to a
>separate source file (detail).

Yes, it became quite big, you're right. It's quite practical for me to
have functions and helpers at the same place but some parts could be
separated.

>You have to call p.start() manually

Yes. Calling start() will move the machine in its initial state and
call on_entry on the machine and the initial state.
You have to call it explicitly because sometimes you simply don't want
on_entry to be called at the creation of the state machine.

>Thanks for submitting this excellent library.

I'm happy that you like it.
Thanks for the great work you put on the review.

Regards,

Christophe