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

From: Robert Bell (belvis_at_[hidden])
Date: 2004-05-26 14:23:58

Andreas Huber wrote:
> Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:
> 
>>He's definitely the expert on the subject in question. Exception handling
>>aside for a moment, I still would strongly prefer to have separate
>>entry/exit methods in the state object interface; it more clearly relates to
>>the conceptual view of FSMs. And, while we're at it: perhaps the
>>entry()/exit() points should be user configurable (per-state-type) to
>>correspond to the UML notation e.g. "entry() / init()",  "exit() /
>>cleanup()" IIRC.
> 
> Again, this is a matter of simplicity. Agreed, entry() and exit() are more 
> understandable for someone who is proficient in the FSM domain. However, how 
> long does it take to explain that the entry action is mapped to the state 
> constructor and the exit action is mapped to the state destructor? Probably 10 
> seconds. If something can be explained that quickly, I'm very sceptical about 
> the benefit of introducing a *new feature* just for the sake of 
> understandability. Remember, even if we had entry() and exit(), we would still 
> need state objects that are created on entry and destructed on exit. This is 
> crucial to satisfy the scalability requirements.

Here's one argument in favor of entry()/exit() over 
constructor/destructor. If you use constructors/destructors, your hands 
will be tied if someday you want to change your mind about the 
implementation of state entry and exit constructing and destructing 
states (a couple of alternatives have been discussed here, such as 
constructing states when they're entered but not destroying them when 
they're exited). If instead you implement entry and exit with entry() 
and exit() member functions, it doesn't matter if the states are 
constructed and destructed as they are now, constructed at entry point 
and destroyed at machine destruction time, or constructed all at once at 
machine construction time.

I don't have any idea if this flexibility is important or not, but if I 
was implementing fsm, I'd consider it.

Bob