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