From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-26 10:49:07
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.
> As I haven't been following your discussion with Dave; is this also a
> performance concern (function call overhead)?
Yes, I think so. I currently don't see any way how entry()/exit() could be
implemented without causing overhead for people not using them, although I
vaguely recall that Dave once hinted in this direction.
Regards,
Andreas