Re: [boost] [msm]exit pseudo state and event

Subject: Re: [boost] [msm]exit pseudo state and event
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-07-21 19:56:06

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