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

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-23 17:18:23

"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message 
news:a2b17b60806211502i447c22e1t9d552dd76b8972a1_at_mail.gmail.com...
>> <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>()
>  }
> };

Yep (Z should of course also be defined somewhere).

>> 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.

So you're suggesting that simple_state::simple_state() should be overloaded 
say 10 times, one templated overload for each distinct number of parameters?

> If someone wants to pass arguments to X, then they should transit to
> X, and X transit to Y IMHO.

Transiting to X could be semantically different from transiting to Y. In the 
diagram discussed so far it's not but looking at the transitions triggered 
by e3 and e4 in ...

http://i.cmpnet.com/embedded/gifs/9901/9901feat1fig4.gif

... you'll see an example where it is. Transiting to S0 leads to the entry 
of S0 and S0_1 while transiting to S0_2 leads to the entry of S0 and S0_2.

> 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.

I wholeheartedly agree, but apart from your factory suggestion I've not yet 
seen any good ideas how this could be improved. Even if we were to go the 
factory route (my version), you'd be forced to implement quite a few factory 
classes (I guess approximately one for each state ctor with parameters). 
Sure this is better than anything we have now but it's not particularly 
elegant.

> 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*>...

You could make your events visitable, in which case you could do with a 
finite number of casts/virtual function calls for any number of state ctors. 
Of course, this would require the implementation of a visitor class, which 
isn't exactly elegant either.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.