Subject: Re: [boost] [msm]exit pseudo state and event
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-07-21 19:56:06
> 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.
> > 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.
> > 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
> - 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk