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

On Thu, Jun 26, 2008 at 6:16 PM, Andreas Huber wrote:

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

[snip]

...

I see that your example is related to history. Isn't it more related to how the state was, rather than how the state will be?

I don't think I understand. The only purpose of the history example was to show that you can't always predict at compile time exactly what inner states will be entered when you transition to a certain outer state. In the CameraWithHistory2 case, as a result of the transition triggered by EvShutterReleased, you will enter either Idle *or* Configuring, so you might want to specify ctor arguments for *both* states.

I'll need more time to think about history. [snip]

Not IMO, because "cascade" + "outer" suggest that there's a natural order that does not exist for inner states. Sure this is "just" naming and is easily resolved but I'm also not very fond of the the chaining interface (no technical reason just personal preference). I would much rather have something like this:

transit<MyState>(ctor<SomeOtherState>(1, 42), ctor<YetAnotherState>(24), ...)

This syntax can be achieved the same way the other one I think. template struct ctor_definition ctor(Arg0, Arg1, ...); template sc::result transit(Ctor0, Ctor1, Ctor2, Ctor...); You can construct the factories in transit and pass to the state_machine.

You wouldn't mention states with default ctors. Also, you can mention the states in any order you see fit. Would this work for you?

Yes, surely. But I'm a little unsure how this plays with history.

Disclaimer: I'm not yet sure whether this interface is implementable with reasonable effort. It might turn out *very* tricky with history.

History seems the main problem here. [snip]

Regards,

-- Andreas Huber

I'll give more thought to history and then hopefully I can give better suggestions. Thanks, -- Felipe Magno de Almeida