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