Hi,
eUML makes up *~75%* of Msm's code and ~30% of Msm's documentation; metrically, it's obviously an extremely significant part of Msm, and is probably what warranted a major version increment between Msm versions 1.2 and 2.0.
Correct. Although it is not the only reason, there is also a big redesign with division in front- and back-ends and riddance of the CRTP. Adam Merz wrote:
I could be way off here, but my impression from the Msm documentation is that the standard frontend exists mostly for backwards compatibility with 1.x code and to support older compilers, and that eUML is the recommended frontend for new FSMs on supported compilers
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.
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.
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?
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. eUML being a representation of the underlying MSM philosophy, I doubt that you will have it. 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. Christophe