I'm sorry. I omitted too much information. Please let me explain step by step.
1.When the transition process exiting the substatemachine, We sometimes need if/else transition outside of substatemachine. 2.In the case above, we can use the anonymous transitions for else transitions. But we have to write it the top of same start state group in transition table. I think it isn't natural description. And I asked you to change the evaluation order reverse.
And then, you said it's difficult. And you showed me some reasons. At that time I didn't know the evaluation order was already documented. Hence, I thought changing the order was not big problem, I thought it's only implementation problem.
3.I consider that anonymous transitions for else transition have wider usage. e.g. For implement choice pseudo states using msm.
This is why I said it's not corner case. Sorry for less description.
I get it now. Clearly, it is not a corner case. It's even surprising the Standard foresees "else" only for junctions / choices. This would make sense for other cases.
If my understanding is right, we don't need the following expression.
struct Empty : public msm::front::state<> { struct internal_transition_table : mpl::vector< a_internal < cd_detected , Empty, &Empty::internal_action >
{}; };
Are you saying we don't need internal transitions? I'd disagree then. They're the best way to implement taking action without changing state.
No. UML's internal transitions are important. Msm provides some options to implement it.
Without eUML, functor front-end is preferred. http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s03.html#d0e1396 // Start Event Next Action Guard Row < Empty , cd_detected , none , none , internal_guard >,
We can describe internal transitions to set Next to none. Is it right?
g_irow is almost same. // Start Event Guard g_irow < Empty , cd_detected ,&p::internal_guard>
I think they are needed.
I only mean internal_transition_table is not mandatory. http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s02.html#internal...
Because we already have the machanism that controls the evaluation order from inside substatemachine to outside.
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.
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 ;-)
If we want to give the internal transition higher priority, we should write the statemachine like fig2.png. In the case of fig2, only the internal transition would be handled.
Do you agree?
No for the reasons I wrote above, but I can't prove you wrong.
But we can control the evaluating order using the Row's sequence. (I think it is out of UML standard.)
It is, but we won't care too much, right? :)
e.g.
// Start Event Next Action Guard Row < Empty , cd_detected , none , none , internal_guard >, Row < Empty , cd_detected , State1 , none , another_guard >, or // Start Event Next Action Guard Row < Empty , cd_detected , State1 , none , another_guard >, Row < Empty , cd_detected , none , none , internal_guard >,
I'd like to know why internal_transition_table is needed. I think transition_table is enough.
See above. Yes it's not needed but I find it pretty useful in everyday's life. This is of course a matter of taste.
If you're at implementing stuff for msm, I might consider another solution: - a typedef in the front-end, which will change the reading order of the table, no to break other's code
Thanks for good suggestion. I'd like to consider a little more:)
Sure :)
- replacing in dispatch_table reverse_fold by fold to change the reading order if typedef is requesting it. - adding rows (frows) at the top instead of bottom.
This leaves us with the hard part, reading the ids in the correct order. For this, we need to find out which one of the transition table transformations is the correct one. I didn't look at it yet, but I imagine it could be tricky. Then use it to read the id from up to down.
I understand you like this feature, but I need to also consider the wishes of those who requested me very useful features some time ago and are waiting for them. So it's also my job to allocate my scarce development time (my evenings) where I think it will be the most useful. For example, the junction pseudo-state you requested seems to me to have a much higher gain for all of us.
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. Regards, Christophe