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

"Felipe Magno de Almeida" wrote in message news:a2b17b60806232137m14a6062bx4389668c0974e639@mail.gmail.com...

On Mon, Jun 23, 2008 at 6:18 PM, Andreas Huber wrote:

...

"Felipe Magno de Almeida" wrote in message news:a2b17b60806211502i447c22e1t9d552dd76b8972a1@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 w = create( _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 fusion::vector inner_state_arguments(T0 a0, T1 a1);

We could write:

struct Z : sc::simple_state { Z(int, int); };

struct Y : sc::simple_state { 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.