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-05 09:25:54

On Mon, 4 Jul 2011 21:42:38 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:

> >> This is a personal choice but these reasons matter to me more than the 
> >> extra
> >> complexity added by a template parameter.
> >> If your taste is the Standard one, it is fine with me, just define "none" 
> >> as
> >> event parameter.
> 
> >In my approach (using none), it is also possible to implement that
> >"if/else" mechanism.
> >See the attached file.
> 
> I think you might have forgotten the file. I'll try to answer without it. 
> Please correct me if I get it wrong.
> If your plan is to add some guards to the transitions starting from the 
> pseudo exit, this is not UML conform as guards are not allowed there (not 
> that it matters to msm, I usually have great pleasure to ignore the 
> Standard's restrictions ;-) But other tools might care).

Same here.
I completely agree with your stance that overcome the lack of
UML standards.

> >We can access the "stored" event parameter in guard functor.
> >(Use the get_param() instead of get_result().)
> >Of course some public interface is required in State1_.
> 
> Sure but I'd prefer to avoid this. It means attributes in State1_ which are 
> only valid when the pseudo exit is used.

Yes. The attributes lifetime is mismatch the valid value.
It's an ugly point of this approach.

> >There are two different ways of thinking about dependency.
> >
> >A.
> >The event that occurs in the sub state machine is submachine’s concern.
> > If outside state machine want to know which event is occurred in 
> > submachine,
> >submachine should provide the proper interface.
> 
> I understand but it's not my programming style because, as stated above, it 
> means attributes in the submachine, which are only valid in a certain 
> scenario, meaning in a certain... state of the submachine. These attributes 
> will need a default value, will need to be reset after the call, could be 
> called at a point where they are invalid, will need some special work of the 
> submachine (ex: when to reset them? Just after the transition? When is it? 
> How will the caller know whether they are valid?). Quite some work.
> I prefer going generic. The main machine has no idea about the event type, 
> only that it provides a certain method.
> Of course I understand that templates are not everybody's stuff. Luckily, 
> msm allows both ways :)
> If you feel more comfortable with submachine methods, it's fine.
> 
> >Of course we can know not only events but also everything occurs in 
> >submachine.
> >For example action result in submachine.(See 12_InsideOutsideInfo.cpp)
> 
> Sure you can. Whether you want this or not is a matter of taste.
> 
> >B.
> >Events are the concept separate from state machine (and sub machine).
> >They exist independent. Hence the mechanism should treat events 
> >exceptionally.
> >
> >My opinion is A. But I can understand B.
> >What do you think?
> 
> 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)
   More generally, does the msm provide interfaces that send events to 
   their own state machine?
2. Add the mutable variable to event classes, and modify the variable in
   action functor. 
   I think it is ugly.

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?

> Regards,
> Christophe 

Thanks,
Takatoshi