Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-04 08:30:25

Hi all,

Looks like there was a fair bit of discussion ;-) I'll try to give my
take on the many discussed points.

Jeffrey Bosboom wrote:
>But I think this concern can be addressed if there is a documentation
>page that compares the libraries that is included in (or linked from)
>both libraries' documentation.  This would make it much easier for a
>user to choose one or the other without having to read the full
>documentation for each.

This sounds like a good idea to me. Not everybody followed the review.

Andrew Venikov wrote:
>I think an even better example would be map and hash_map.
>They serve almost identical purpose but using totally different
>techniques. The user of stl is expected to understand the differences
>and chose the appropriate container.
>Why not do the same with SC and MSM?

Yes, we should really write a page explaining the trade-offs.

David Bergman wrote:
> I would even have welcomed some macros that introduce the state declarations for simplistic states,
> from that transition table expression.

There is something like this in eUML (on compilers with native
typeof). Is this ok for you?
typedef BOOST_TYPEOF(build_state( )) Paused;
I can of course also add a macro for other compilers.

David Bergman wrote:
>Well, well, I seem to be the only one caring about this, and MSM sure is a fine library,
>so I say 'welcome metamagical states!'.
> NOTE: no, this was not a formal review ;-)

I would welcome a formal review though. It'd help the review manager
make a decision ;-)

Jeffrey Bosboom wrote:
>Decide whether MSM should be included or not on its own merits.  If so,
>then MSM makes Boost better; we shouldn't be so concerned with being
>perfect that we lose the opportunity to be better.

I agree. We should always decide on a library's merit and then see how
to handle it. It'd be sad to lose
an opprtunity to make boost more valuable on organisatory grounds.
This doesn't apply only to MSM.

David Bergman wrote:
>You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys
>on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though.
>If that would have led to a combined Statechart 2.0 (analogous to Spirit 2.0) in a year, I would wait.

Merging would be quite hard. While both libraries seem to have almost
the same interface, scratching the surface will
show many differences. The reason is that both libraries follow a
pretty different philosophy and use different techniques.

The best which might be achieveable would be a new front-end in MSM
trying to match as much as possible SC's front-end.
It would probably work for simple state machines. It might even work
for composites. I'm not expert enough in Statechart
to tell if more is possible.
And the question is if someone would ever need this. You would still
get the compiler limitations (and maybe add some
more due to the added metaprogramming) and not all of SC's features.
Why to use it then?
However, if someone is willing to take this task on, I'd be ready to help.
Ideally we would have to do the same in Statechart for one of MSM's
front-ends. Sounds like a lot of work.

Christophe