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

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-19 16:22:51

"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message 
news:a2b17b60806182303u493e7061i8d36d68c59d27f1e_at_mail.gmail.com...
>>> I would really want to pass a state instance to transit<>().
>>> Why isn't this available?
>>
>> Um, why do you want pass a *state* object to transit<>()? State 
>> construction & destruction must be done by the state machine itself.
>
> I understand it conceptually, but practically I can't see much
> difference from I constructing it or
> the machine doing it.

A state constructor is the entry action of a state and the destructor is the 
exit action of a state (there's also exit() but let's ignore that for the 
moment). Now, during a transition these actions must be called in a 
well-defined order (as mandated by UML, Harel, etc.). If you construct the 
destination state before the origin state is destructed then said order is 
violated.

> All I wanted is to pass constructor arguments.
> Explicitly or not.

I do agree that this is sometimes desirable. So far, I have worked around 
this by posting an event carrying the data (often, the posted event is a 
copy of the event triggering the transition). The destination state simply 
defines an in_state_reaction to pick up the previously posted event. Sure, 
this is kind of ugly.

> The machine would have to copy the state, but I don't mind if at least
> I can give
> arguments to the next state somehow.
> Can't we pass the arguments to transit<>() ?

I guess we could, but as mentioned this requires some pretty involved 
compiler magic.

> I'm not an expert in statechart implementation, but it shouldn't be
> that hard, transit<>
> could pass a boost::factory to the statechart internals responsible
> for instantiating a state.

Hm, something along these lines might actually work. Remember though, that a 
transition could potentially create more than one state object, so an 
example factory object could look like this:

class MyStateFactory
{
  public:
    MyStateFactory(/* arguments that should be passed to state ctors */)
    {
      /* store arguments in data members */
    }

    template<class State>
    boost::intrusive_ptr<State> construct()
    {
      return new State(/* ctor arguments here */);
    }
};

construct() would be called once for each state that is created as a result 
of a transition. If you want to treat different state types differently 
you'd need to specialize.

Thoughts?

Regards,

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