Re: [boost] [msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)

Subject: Re: [boost] [msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-05-31 15:37:48

Hi Takatoshi,

> I wanted to explain that as follows:
> "hi, I'm a submachine and I provide the following entry points: Entry1
> accepts any events. Because I don't care that. "
>
> Let me introduce more practical example that requires entry_pseudo_state.
> ScanFinger.png is a sub-machine. This sub-machine's primary purpose is
> to scan fingerprint. Before scanning, the sub-machine checks that
> finger is alive or not. But it's optional. To skip this check
> procedure, the entry point pseudo state ScanOnly is provided.
>
> FingerPrintRegister.png is the parent state machine. It uses
> ScanFinger as a sub-machine twice. In this scenario, alive checking is
> not required. So, the parent machine uses ScanOnly enty_pt. In another
> scenario, not mentioned here, might require the normal entry into
> ScanFinger to check the finger is alive.
>
> ScanFinger machine doesn't care about outer event. In
> FingerPrintRegister, the states RightScnning and LeftScanning have
> different incoming events for ScanOnly entry points. But any events
> are accepted. And then, it's not referred.
>
> Based on your suggestion, I introduce the base event class. As long as
> the incoming event of entry point is not "none", this approach works
> good.
>
> struct AnyEvent {};
> struct Completed: public AnyEvent {};
> struct StartButtonPressed: public AnyEvent {};
> (See 39_FingerPrintExampleBaseEvent.cpp)
>
> If the incoming event is "none", the transition is stopped. Sometimes
> I want to use "none" as incoming event for entry point in the same
> sub-machine.
> And it is impossible that msm::front::none inherits user event classes
> such as AnyEvent.
>
> I'm trying to find better approach to solve the above problem.

>I realized that I should use explicit_entry instead of entry_pseudo_state.
>UML's entry point pseudo states should be mapped into
>msm::front::explicit_entry.
>
>For example, entry point pseudo state Entry1 in ScanFinger should be mapped
>            struct Entry1:msmf::state<>, msmf::explicit_entry<> {};
>not
>            struct Entry1:msmf::entry_pseudo_state<> {};
>
>There is no restriction that relates to Entry1's outgoing event :)
>
>I forgot to rename Entry1 to ScanOnly. Please consider that they are same.
>
>IMHO, the semantics of UML's entry point pseudo state look more like
>Boost.Msm's explicit_entry than entry_pseudo_state.
>
>I believe that I found the best solution of my problem.
>
>Thanks,
>Takatoshi

Please, no! Not the explicit entry ;-)
This is the feature I'm the least proud of...

Actually, it's funny, we got the same idea. We need the concept of an "any" 
event. Some people called it kleen during the review.
I have a solution which looks very promising, I need to polish it before I 
can commit.
There will now be an any event, which will match whatever event is 
processed. Note that this is not "none", which has a different behavior.
I thought a bit last night after our last discussion and I come to such a 
transition in your first example:

====>  msmf::Row < Entry1  , boost::any, State2_2  , ExecuteEntry, 
msmf::none >

Not that the event now is boost::any. And it matches your Event1 of course. 
This way you get the same effect as your none and I keep my event data as I 
can any_cast (note to self, also plan to support Steven's new pimped any. 
Name suggestion: boost::pimped_any :) ).

The added advantage is that this will apply to all of MSM's transitions, not 
just pseudo entries.

Would this be an agreeable solution to you?

Regards,
Christophe