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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-06-21 18:02:53

On Fri, Jun 20, 2008 at 4:47 PM, Andreas Huber
<ahd6974-spamboostorgtrap_at_[hidden]> wrote:
> "Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message

[snip]

>>> I was thinking more that boost.statechart would always use a functional
>>> factory,
>>> like boost::function<State*>() 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<Y, Z>
{

};

struct Y : sc::simple_state<Y, X, Z>
{
};

struct B : sc::simple_state<B, A>
{
  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<e1*>...
else if(e2* p = dynamic_cast<e2*>...

> Regards,
>
> --
> Andreas Huber

Regards,
-- 
Felipe Magno de Almeida