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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-06-26 17:33:06

On Thu, Jun 26, 2008 at 6:16 PM, Andreas Huber
<ahd6974-spamboostorgtrap_at_[hidden]> wrote:
> "Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message
> news:a2b17b60806241815r4f0c6e5fpbfde9454701837d5_at_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 <typename State, typename Arg0, typename Arg1, ...>
struct ctor_definition<State, Arg0, Arg1, ...> ctor(Arg0, Arg1, ...);

template <typename MyState, typename Ctor0, typename Ctor1, typename
Ctor2, typename Ctor...>
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