Re: [Boost-users] [statechart]historytransitionsmakestate-local-storage "un-cool"

21 Jun 2008

      On Fri, Jun 20, 2008 at 4:47 PM, Andreas Huber
 wrote:
...
"Felipe Magno de Almeida"  wrote in message
[snip]
...
...
...
I was thinking more that boost.statechart would always use a functional
factory,
like boost::function() to instantiate states.
Which works for the construction of the destination state but not for the
construction of possibly also entered outer and inner states of the
destination state. For example, please have a look at the following chart:
http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/LCA.gif
Ok, if I understand the diagram correctly, this is what happens:

struct Z : sc::simple_state
{

};

struct Y : sc::simple_state
{
};

struct B : sc::simple_state
{
  typedef sc::custom_reaction< Ev > reactions;

  boost::statechart::result react( Ev const& e)
  {
    // do something
    return transit<Y>()
  }
};

IIUC,
...
During the transition triggered by the event Ev, the states X, Y and Z are
entered and thus constructed. IIUC, with your approach it is only possible
to pass arguments to the constructor of Y, but not to the ones of X and Z,
correct? The solution I have in mind (see code in previous post) would allow
you to selectively provide whatever arguments you might want to pass to X, Y
and/or Z. Admittedly, passing arguments to outer and inner states of the
destination might be a less frequent use case but I'd still rather not rule
it out.
Thoughts?
IIUC the diagram, the functional factory solution allows both Y and Z
to have arguments to its
constructors.
The Y state could pass the arguments to its base with the arguments
for Z constructor, which
would then create a factory to instantiate Z.
If someone wants to pass arguments to X, then they should transit to
X, and X transit to Y IMHO.
I see your triggering_event idea, and I find it not very useful
because of its necessary downcast
and dynamic typing, it also seems to me that the reponsability to
receive the arguments continue
to be in the just-entered state. Which I find dissatisfying. If I have
three or four state constructors,
each with different parameters, how would that be implemented with
triggering_event?
I hope not like this:

if(e1* p = dynamic_cast...
else if(e2* p = dynamic_cast...
...
Regards,
--
Andreas Huber
Regards,
-- 
Felipe Magno de Almeida