Hi, Christophe <...snip...>
Strictly speaking, no, it's not mandatory. The goals of internal_transition_table are: - ensure the transitions withing it have a higher priority - make the state more reusable and more useful when reused.
I understand your design decision. <...snip...>
And UML standard said that internal transitions are not relate to priority. There are no guaranty that internal transitions are evaluated faster than another (non internal) transitions if they have same start state.
Consider fig1.png. Thease two transitions have same priority. At least in UML specification, we don't have a guaranty that which transition would be handled. But one of them would be handled.
True, the Standard is vague about this, which caused me some headaches ;-) My decision on this matter is discussable, so please allow me to explain. After thinking hard about it, I came to the conclusion that this was just another variation of the Liskov substitution principle (I do use other sources than the Standard ;-) ). In your fig2, State1 is a submachine. Then its internal transitions have a higher priority, right? Now imagine I redesign it and make it a simple state (your fig1). Then if I follow your interpretation, the priority will change, thus breaking the implicit contract I had with the state machine which State1 was and my behaviour would silently change. This would lead to subtle bugs. In this spirit of this principle, I decided the only logical solution was to treat internal transitions as "more internal" and having a higher priority. Of course I also edged my bets and allowed the variation with transition_table ;-)
You introduced new priority rule below. Internal transitions have higher priority than normal(outer) transitions which have same state state. I agree with your additional rule. It's reasonable. BTW, I often want to another expansion below. When internal transitions are invoked, the trigger event isn't consumed and evaluating process continues. But it is another story. <...snip...>
Yes. I understand your situation. I agree this request is not high priority. And the request is not reasonable enough at this time.
Oh it is reasonable, I'm just trying to build first what will make the most people happy. To show my point, I am working on: - a rewrite of the ugliest parts of eUML, the current state is not satisfactory - support for thread-safe usage, asio usage, etc. - improving my test coverage I think we all agree that is is badly needed...
Also I'd like to know your design philosophy of msm. I would ask you some questions.
Sure, but for the record, a big part of it is not from me but from a chapter from Dave and Aleksey's book (http://boostpro.com/mplbook). This is the base for MSM.
Yeah! I have this book. It's translated in Japanese. And on the front of the book, Dave's autograph is exist!! I understand the basic concept of msm, Now I'm digging deeper area.
Regards, Christophe
Thanks, Takatoshi