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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-06-24 00:59:55

On Tue, Jun 24, 2008 at 1:37 AM, Felipe Magno de Almeida
<felipe.m.almeida_at_[hidden]> wrote:
> 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]

>>> 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?
> This is not rhetorical actually, I'm a little inexperienced with
> developing state machines.
> So far I've writed a SMTP client with asio, and am creating a SMTP server.
> I have no other experience with state machines.

Actually, I have myself an use case for passing arguments to outer states.

I'm just throwing here a suggestion:
How about having another way of transiting in this case?

cascate_transit<state1>(inner_arg1, inner_arg2)
  .outer<state2>(middle_arg1, middle_arg2)
  .outer<state3>(outer_arg1, middle_arg2);

template <typename State0, typename State1 = nil, typename State2 = nil, ...>
struct cascate_transit;

struct typename State0, nil, nil, ..>
{
  template <typename OuterState, typename A0, typename A1, ...>
  cascate_transit<State0, OuterState>
  operator()(A0, A1) const;
};

I don't know how to get a functor to the code that instantiates the
state, nor I know
where it is instantiated.
But I can implement the commands that get the arguments without problem, if
you're willing to have this added to statechart.

And completely off-topic:
Also, a state that is instantiated through tss (when multithreaded),
or through a
global variable (when single-threaded) could be good. This is how I have
the implementation windows initialized in my cppgui library before
the derived user classes. Without requiring the user to pass along a context.

[snip]

-- 
Felipe Magno de Almeida