Re: [boost] [statechart] Completion transitions again.

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.