From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2007-08-31 14:47:54
"Leandro Lucarella" <llucarella_at_[hidden]> wrote in message
news:46D84A2E.3070008_at_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.