Re: [boost] [msm]exit pseudo state and event

Subject: Re: [boost] [msm]exit pseudo state and event
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-07-13 15:48:06

>> > Off the top of my head, how about the functor Else_ below?
>> > Else_ <Guard1, Guard2, Guard3, ... >
>>
>> For else, we can use the fact that msm tries guards from the bottom of 
>> the
>> table to the top:
>>
>> // else clause
>> Row< state1, ev, state2, none, none>,
>> // if clause
>> Row< state1, ev, state2, none, Or_<...> >
>> // more if clauses
>> ...
>
> Fantastic!
> This has 2 advantages and 1 disadvantage.
>
> Advantages:
> One is simple enough. The other is good performance.
> It doesn't need evaluating the guard functor twice.
> I was about to consider how to cache the functor's result.
>
> Disadvantage:
> As you might expect, the evaluating direction is opposite of my intuition.
>
> Are there any reasons of this implementation?

There are.
It's an implementation detail which dates back to the early phases of the 
library (start + 3 months).
The reason is that msm adds, for performance, rows for submachines at the 
end of the table (one for every event found in the submachine), then starts 
processing from the bottom to give these rows a higher priority (UML rule).
At the same time, the library also uses the table to generate state ids 
(http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch06s03.html).
I could do the opposite (extra rows at the beginning) but it'd be pretty 
hard to guess after this what the state id you get in no_transition means 
(it's already hard enough to explain the current order, imagine if I had to 
explain you have to count in reverse order...).
And as the else feature is not in the Standard, it seemed ok.
In these early phases I didn't have, like now, different steps of transition 
table processing.
This old decision could deserve some revisiting, but:
- there are a few corner cases which could make a change pretty tricky 
(pseudo entry/exit states)
- some people already use the current implementation state, so it'd break 
their code, I'd need some compile-time configuration, which would get hidden 
deep in the already big doc. The default would still be the current order.

> Modifying to the opposite direction is easy?

Unfortunately not, so considering the gain and the time it'd cost, it's 
unlikely to change until I have nothing else to implement in the library, 
which could take some time ;-)

Regards,
Christophe