Boost logo

Boost :

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2007-08-31 14:47:54

"Leandro Lucarella" <llucarella_at_[hidden]> wrote in message
> 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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at