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.