[boost] Re: [prereview request][fsm]

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-25 09:25:17

Andreas Huber <ah2003_at_[hidden]> writes:

>> > Are you proposing that an active state should still be represented by an 
>> > object, 
>> 
>> I don't have enough knowledge of the FSM domain to say whether that's
>> a good design or not; I have to trust you that it makes sense to have
>> a correspondence between states and distinct types whose instances'
>> lifetimes correspond to the time spent in the state.
>
> That an active state is represented by an object is crucial to satisfy the 
> scalability requirements. Otherwise adding a variable that is used only in a 
> part of the machine would lead to the recompilation of the whole state machine.

OK.

>> > which acquires resources and executes entry actions in its
>> > constructor, releases resources in its destructor but executes exit
>> > actions in a separate function, which is called just before
>> > destructing the state object?
>> 
>> Yes, that's basically what I was saying.
>
> This is certainly doable. However, I'm unsure whether the current design 
> allows a you-don't-pay-for-what-you-don't-use implementation of such a 
> feature. Plus, I'm still not convinced that this feature would be used more 
> than rarely. Do you have some real-world use cases in mind?

Unfortunately I'm not so familiar with what exit actions in FSMs are
typically used for, but from an abstract point of view I don't think
of resource releasing as an "action".  If you were writing this stuff
in a GC'd language, for the most part, you wouldn't devote any exit
action code to resource releases.  So I figure there must be some
other reason people want exit actions, and since they seem
symmetrical to entry actions in some ways, I don't see why you'd want
to prohibit exceptions there.  If anything, I'd want to prohibit
exceptions in entry actions, since those can lead to the FSM being in
a state from which it's impossible to continue.  At least with exit
actions, you can stay where you are and keep all your FSM's abstract
invariants intact.

> If this is needed only rarely I'd rather have users work around the
> problem by setting a boolean and posting an error event in a failing
> exit action and then testing that boolean in all following exit
> actions.

Eeeeew, that's gross.  Sorry, but that just smells like an awful
hack.  Why not just call the state object's exit() member function if
it has one?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com