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

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-24 15:57:56

"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message
news:a2b17b60806232137m14a6062bx4389668c0974e639_at_mail.gmail.com...
> On Mon, Jun 23, 2008 at 6:18 PM, Andreas Huber
> <ahd6974-spamboostorgtrap_at_[hidden]> wrote:
>> "Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message
>> news:a2b17b60806211502i447c22e1t9d552dd76b8972a1_at_mail.gmail.com...
>
> [snip]
>
>>> 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?
>
> Yes. This can be done very easily with boost.preprocessor.
[snip]

I know, I just wanted to ensure that we're on the same page.

> If you find it too inconvenient, a simple fusion sequence works too.

I'll have to have a look at fusion sequences then.

> In my cppgui library I use a fusion sequence to allow passing argument
> constructors
> to windows:
>
> wnd<my_window> w = create<my_window>( _arguments =
> fusion::make_vector(a1, a2, a3) );
>
> But since this lib uses boost.named_parameters, I can't pass multiple
> arguments to it,
> so a sequence is the only thing that fits. Maybe as syntactic sugar
> this could be done,
> instead of overloading simple_state constructor.
>
> template <typename T0>
> fusion::vector<T0> inner_state_arguments(T0);
>
> template <typename T0, typename T1>
> fusion::vector<T0, T1> inner_state_arguments(T0 a0, T1 a1);
>
> We could write:
>
> struct Z : sc::simple_state<Y, Z>
> {
>  Z(int, int);
> };
>
> struct Y : sc::simple_state<Y, X, Z>
> {
>  Y() : sc::simple_state(inner_state_arguments(0,1))
>  {}
> };

IIUC, then Y as defined above would require that all its inner states have a
constructor with two integer parameters. I think this is too limiting.

>>> 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 understand. But if someone is trying to transit directly to an
> inner state, does he care about the local-state of the new outer state?

In my experience, I would expect that he *usually* doesn't, but only
usually.

>>> 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.
>
> I hope I convince you of my idea then. :)

I'm sure we'll be able to agree on some form of ctor support.

>> 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).
>
> I don't think creating classes is a good idea. The constructors would
> still
> be fixed.

I'm not sure I understand. How are the constructors "fixed" with the factory
approach I suggested? How are they not fixed with other approaches?

Regards,

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