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
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
On Dec 7, 2009, at 11:21 AM, David Bergman wrote:
I enjoy being critical of things I like, which is why I always criticize my wife.
That'll get you far; take it from me. For what it's worth, I think that, to the extent that having a library accepted at Boost is a disincentive to developing better libraries in the same domain, we have a problem. I don't mind you asking the question "should there be multiple libraries in the same domain?" My answer is yes. -- David Abrahams BoostPro Computing http://boostpro.com
David Abrahams wrote:
On Dec 7, 2009, at 11:21 AM, David Bergman wrote:
I enjoy being critical of things I like, which is why I always criticize my wife.
That'll get you far; take it from me.
For what it's worth, I think that, to the extent that having a library accepted at Boost is a disincentive to developing better libraries in the same domain, we have a problem. I don't mind you asking the question "should there be multiple libraries in the same domain?" My answer is yes.
To me the question is simple - should MSM be accepted into boost. The other question - should state chart be deprecated - is really a different question. Discussion of this question isn't really related to the review of MSM. That is, the answer to the second really doesn't impact the first. Confusing these to issues doesn't really help the review of MSM. Robert Ramey
On Dec 7, 2009, at 12:05 PM, Robert Ramey wrote:
I don't mind you asking the question "should there be multiple libraries in the same domain?" My answer is yes.
To me the question is simple - should MSM be accepted into boost.
That too, but it's not the question I was referring to (see above).
The other question - should state chart be deprecated - is really a different question.
Also not the question I was referring to (see above).
Discussion of this question isn't really related to the review of MSM. That is, the answer to the second really doesn't impact the first. Confusing these to issues doesn't really help the review of MSM.
True. I'm making a larger point. Sorry if it seems off-topic here; like you, I imagine, I was really hoping we could put this part of the discussion to bed for now. -- David Abrahams BoostPro Computing http://boostpro.com
On Dec 7, 2009, at 3:05 PM, Robert Ramey wrote:
David Abrahams wrote:
On Dec 7, 2009, at 11:21 AM, David Bergman wrote:
I enjoy being critical of things I like, which is why I always criticize my wife.
That'll get you far; take it from me.
For what it's worth, I think that, to the extent that having a library accepted at Boost is a disincentive to developing better libraries in the same domain, we have a problem. I don't mind you asking the question "should there be multiple libraries in the same domain?" My answer is yes.
To me the question is simple - should MSM be accepted into boost.
I agree, but for me the fact that there is a library in Boost fulfilling most of my FSM needs is a factor in that decision. I do not understand why this is regarded so outrageous.
The other question - should state chart be deprecated - is really a different question. Discussion of this question isn't really related to the review of MSM. That is, the answer to the second really doesn't impact the first. Confusing these to issues doesn't really help the review of MSM.
I do not confuse these matters, just have a different take on multiplicities of domains in Boost than yours, or Dave's. /David
participants (4)
-
Christophe Henry -
David Abrahams -
David Bergman -
Robert Ramey