[boost] Re: FSM Review

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-07 13:58:33

Hi Peter

Thanks for your review!

Peter Petrov wrote:
> To me, the design is good and follows naturally from the objectives of
> the library. It imposes some restrictions, although they can be
> overcome if necessary (for me it has not been necessary). For example, 
> machines
> don't recognize polymorphic events, therefore they cannot "forward"
> unknown events to another machine. This can be circumvented by using a
> "wrapper" event around such events, which works, but only with
> asynchronous machines.

There's going to be a much nicer way of reacting to all events. I will 
add event_base specializations for all reactions.

> Another example is the way that state machines
> are inherited - it's not very flexible and only allows altering how a
> state machine reacts to an already recognized event. One cannot add
> support for new events, except using again the "wrapper event" trick.

Support for new events should be possible indirectly when you have a 
derived FSM transition to a new substate. However, I admit that it is 
cumbersome.

>     * The library documentation contains
>       few not yet solved issues (name,
>       separating the library into two parts,
>       exception handling). What is you opinion here?
>
>
> The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating
> the library into two parts, I prefer it being separated, since the
> Worker part is useful by itself.

Ok, noted.

> A possible problem is that states are constructed using operator
> new(). The documentation clearly states that, and the library allows
> overcoming the issue by specifying a custom allocator for the state 
> machine, as
> well as writing custom operator new()'s for all state classes. I
> personally am against the second requirement and think that it
> complicates things too much. Specifying a custom allocator for the
> state machine should be enough.

Doing so would make it impossible to have separate memory management for 
states, which I think is sometimes desirable when there's at most one 
object of an FSM (as I explain in the rationale). I should probably 
measure the difference, it could well be insignificant.

Regards,

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