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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-27 04:19:19

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:loom.20040526T173111-721_at_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