"Andreas Huber" <ah2003@gmx.net> wrote in message news:loom.20040526T173111-721@post.gmane.org...
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.
Isn't good understandability in the public interfaces what libraries are all about (well, perhaps not _all_, but you get my point)?
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.
I got the impression otherwere in this thread that destruction on exit was unrelated to 'scalability', does that not hold?
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.
Policies? // Johan