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-08 06:12:17

On Wed, 6 Jul 2011 23:09:37 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:

> >> I think I'll need your example to understand this question.
> >> Generally, my opinion is that I want the weakest dependency I can get 
> >> away
> >> with. And a dependency to a template method of an event seems to me a 
> >> weaker
> >> one than a dependency to a submachine class. Both ways because the
> >> submachine would also have to make some assumptions about the main 
> >> machine's
> >> behaviour.
> >
> > In the case of event parameter, I completely agree with you.
> > But I'm not sure how to propagate the sub-machine's action result
> > to main-machine without adding the interface to sub-machine.
> >
> > I have two ideas.
> > 1. Using the internal transition. (See 13_PropagateActionResult.cpp
> >   Event2)
> >   Can I call the member function "process_event" inside the action 
> > functor??
> >   (See Line 69)
> 
> Yes. I didn't try your example out but it looks good.

Great!
I think it's a typical pattern that propagate sub-machine's information
to outside state machine via event mechanism.

> >   More generally, does the msm provide interfaces that send events to
> >   their own state machine?
> 
> Sure. That's one of the main reasons to pass the fsm as parameter to the 
> action.
> 
> 
> > 2. Add the mutable variable to event classes, and modify the variable in
> >   action functor.
> >   I think it is ugly.
> 
> I agree :)
> 
> > If there are no good ideas to do that, your approach solves only
> > event parameter. I think it's too partial.
> >
> > I hope 1 is OK.
> > Or do you have any better ideas?
> 
> What you are doing should work without problems.

At first, I was not sure it is correct or not 
that calling process_event recursively.

process_event() -> operator()() -> process_event()

But you pointed out it's no problem.
I can use the msm mechanism flexibly!

> As a side note, I like the Guard1 / Not_<Guard1> construct. It's the best 
> way to ensure that guards are mutually exclusive.

Thanks.
I think that your euml functor is also useful outside of euml as DESL.

The functor Not_ is suitable for "else". 
But if we have much more guards, We have to use Or_ functor like this.
msme::Not_< msme::Or_< msme::Or_<Guard1, Guard2>, Guard3> >

Off the top of my head, how about the functor Else_ below?
Else_ <Guard1, Guard2, Guard3, ... > 

> Regards,
> Christophe

Thanks,
Takatoshi