Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-07 14:21:00

On Dec 7, 2009, at 12:27 PM, Christophe Henry wrote:

> David Bergman wrote:
>> That was not my impression. My impression was that the (old) standard interface
>> was the canonical one, and eUML an "option" for developers.
> 
> MSM has no favorite interface, but a choice of interfaces which it
> tries to support equally well. But it's true that eUML is my personal
> favorite way and the source of a great amount of fun. I personally
> thought (or say hoped) that it'd become the new way of writing state
> machines, but I came into this review without an idea of how it would
> be welcome. From what I saw for reactions until now, I'm pretty
> confident eUML will meet this goal at some point.

As I said before:

        eUML:Statechart :: Xpressive:Regex

So, yes, I like eUML. But, I also like the "standard" way of using rows in a big table, since, although less cute (in a algebraic sense of the word, if there is such a sense at all...), it mirrors the conceptual transition table very well.

>> I would welcome eUML into Boost any day, from what I have seen (especially after playing with it this morning.)
> 
> Great!
> 
>> Do we really need a new underlying library for eUML, though? I am not sure of that.
> 
> You don't get a new library for eUML but eUML for a new library. It's
> clearly not the same.

I understand that :-)

>> And even if we do (for now), and cherish the much faster execution speeds of MSM
>> (in my non-complex but pretty big state machine examples),
> 
> I don't get what is the problem. You get a backend with impressive
> performance which was built with the goal to allow expressive,
> declarative and concise front-ends with great UML support and lots of
> work done under the hood which you can't even imagine. Without it,
> there would be no interface and no eUML. Why not have it? I thought
> that Boost was standing for state-of-the-art C++ coding and was happy
> to get any great library coming, no matter which library is already
> part of it. Don't we all agree on that?

The problem is this: if, *hypothetically*, eUML were the only substantial difference between this proposal and what is already in Boost, I would argue for an implementation of that syntax on top of Statechart to be a more viable solution.

As you spell out here - and I can confirm - that is not the only difference; there are substantial back end differences, making for more performing state machines and pluginability of new front ends. But the aforementioned hypothesis was what I was trying to get at. As you can tell, for whatever lobotomized reason, I tend to view this proposal as three parts: (i) the good old interface, (ii) eUML and (iii) the back end. I understand that some of this separability is actually a result of a unique and quite ingenious implementation on your part, and also that the proposal is all or nothing :-)

>> I would argue for an attempt at having eUML as an optional facade for both MSM and Statechart.
> 
> For this you'd need some important amount of change in Statechart, for
> which I cannot do anything.

Perhaps, I would like to take on that challenge and see how far I can get. I think it would be great to have a common transition-definition format for these two libraries, and being able to switch in compile-time.

> eUML being a representation of the underlying MSM philosophy, I doubt
> that you will have it.

Let me try to look at it a bit, and see what I can do. It would involve a lot of wrappers, unfortunately :-(

> Let me get it straight. The biggest value of MSM is not the front-end,
> not even eUML, no matter how cool it is. It is the back-end. Actually
> it's the philosophy behind the back-end.

I enjoy being critical of things I like, which is why I always criticize my wife. So, take that as a good sign for my formal review (which has already been pushed one day due to my "common interface" sickness :-) )

/David