On Fri, Jun 20, 2008 at 4:47 PM, Andreas Huber <ahd6974-spamboostorgtrap@yahoo.com> wrote:
"Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> wrote in message
[snip]
I was thinking more that boost.statechart would always use a functional factory, like boost::function<State*>() to instantiate states.
Which works for the construction of the destination state but not for the construction of possibly also entered outer and inner states of the destination state. For example, please have a look at the following chart:
<http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/LCA.gif>
Ok, if I understand the diagram correctly, this is what happens: struct Z : sc::simple_state<Y, Z> { }; struct Y : sc::simple_state<Y, X, Z> { }; struct B : sc::simple_state<B, A> { typedef sc::custom_reaction< Ev > reactions; boost::statechart::result react( Ev const& e) { // do something return transit<Y>() } }; IIUC,
During the transition triggered by the event Ev, the states X, Y and Z are entered and thus constructed. IIUC, with your approach it is only possible to pass arguments to the constructor of Y, but not to the ones of X and Z, correct? The solution I have in mind (see code in previous post) would allow you to selectively provide whatever arguments you might want to pass to X, Y and/or Z. Admittedly, passing arguments to outer and inner states of the destination might be a less frequent use case but I'd still rather not rule it out.
Thoughts?
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. If someone wants to pass arguments to X, then they should transit to X, and X transit to Y IMHO. 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. If I have three or four state constructors, each with different parameters, how would that be implemented with triggering_event? I hope not like this: if(e1* p = dynamic_cast<e1*>... else if(e2* p = dynamic_cast<e2*>...
Regards,
-- Andreas Huber
Regards, -- Felipe Magno de Almeida