Re: [boost] [statechart] Completion transitions again.
Andreas Huber wrote:
struct ev: sc::event< ev > {}; struct B; struct C; struct A: sc::simple_state< A, Machine > { typedef mpl::list< sc::completion_transition< >, sc::custom_reaction< ev > > reactions; sc::result react(const completion_event&) { if (guard) return transit< B >(); return discard_event(); } sc::result react(const ev&) { if (!guard) return transit< C >(); return discard_event(); } };
I'm not sure how this is an improvement over the choice-point-like class?
It improves readability and removes the need for a dummy intermediate class?
Again, this limitation can be overcome easily with the same trick. Specify a dummy outermost state as initial state and then post an event in the entry action that will trigger a transition to the desired state.
Ok, my main problem is gone. I can now express what I need with the intermediate dummy state trick. I think the improvements in this limitations are desirable but not critical, and maybe you are right and it's too much work for too little gain. Thanks for your help! -- Leandro Lucarella Integratech S.A. 4571-5252
"Leandro Lucarella" <llucarella@integratech.com.ar> wrote in message news:46D84A2E.3070008@integratech.com.ar...
Andreas Huber wrote:
struct ev: sc::event< ev > {}; struct B; struct C; struct A: sc::simple_state< A, Machine > { typedef mpl::list< sc::completion_transition< >, sc::custom_reaction< ev > > reactions; sc::result react(const completion_event&) { if (guard) return transit< B >(); return discard_event(); } sc::result react(const ev&) { if (!guard) return transit< C >(); return discard_event(); } };
I'm not sure how this is an improvement over the choice-point-like class?
It improves readability and removes the need for a dummy intermediate class?
Let me rephrase: How is the above code an improvement over a *library-provided* choice-point-like class (as I said I'm considering to add such a class)? The only thing I see is that in my approach there is no distinction between a completion transition and a normal transition, but UML doesn't distinguish these either (a completion transition is expressed with the same arrow as a normal transition, the only thing that's lacking is the triggering event). Now let's consider a approaches how the library could provide completion event support (I'm using transitions here but of course a completion event could just as well trigger other reactions): Approach 1, the closest to UML: typedef sc::transition< X > reactions; However, due to the fact that in Boost.Statechart the triggering event has always been the first parameter in all rections, I think the following is more natural: Approach 2: typedef sc::transition< sc::completion_event, X > reactions; For approach 2, the library could find out at compile time for each state whether the automatic posting of a sc:completion_event is necessary. Now, you can also write the following... typedef sc::transition< sc::event_base, X > reactions; ... to express a transition that is triggered by all events. Now the central question is: For states that have a reaction triggered by sc::event_base do we also post an sc::completion_event after state entry? If the answer is yes, then we would break code that was written before the introduction of sc::completion_event. If the answer is no then we would almost certainly astonish new users. I therefore think it is best to introduce the choice-point-like class, which IMO doesn't reduce expressiveness much.
I think the improvements in this limitations are desirable but not critical, and maybe you are right and it's too much work for too little gain.
With the current interface it's theoretically possible to allow full UML semantics but it would require quite a bit of additional compile-time magic, which doesn't really help to improve the currently not so stellar compile-times. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
Leandro Lucarella