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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-28 08:36:21

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:009a01c444ac$a8587690$0600a8c0_at_pdimov...
> Johan Nilsson wrote:
> > "Topher Cooper" <topher_at_[hidden]> wrote in message
> > news:EB688081-B031-11D8-BA4A-003065841348_at_topherc.net...
> >> Hi:
> >>
> >
> > [snip]
> >
> >> A particular mechanism (C++
> >> constructor/destructor behavior) having been identified as being
> >> *analogous* to a desired behavior (entry/exit actions in an fsm), was
> >> then strictly identified with the same, and used to implement it.
> >
> > Well stated. I agree with many things you mention in your posting,
> > and in particular to this.
>
> Please finish reading Topher Cooper's post. In it, you'll find the answer
> to:
>
> >> Everything is possible. The question is: What exactly is the
> >> advantage? What are the use-cases?
> >
> > Library user wants to keep his state alive during the entire fsm
> > lifetime ;-)
>
> The argument is that the "state" is not a FSM state. It is an object that
> represents the condition of an FSM state being active. This condition is
> regarded as a resource, and RAII is applied to manage it. You can't "want
to
> keep the object alive", because that would mean that the FSM state is
always
> active. It's similar to your wanting to keep a mutex lock alive.

Assuming I had the same mental definition of a "state" as the library in its
current incarnation, yes. I'm expressing myself too ambiguosly, with the
only excuse getting a bit tired of the discussion. If it's not a state, as
in FSM state, why call it a state? It's already been a source of confusion
(and not only for me).

I did actually read Topher Cooper's post, but obviously skimmed the
important parts. Now I've given it the time it well deserved.

Perhaps renaming "state" to "state_activation" would clear things up.
However I'm still not convinced that states (state objects corresponding to
FSM states) should be non-existing in the library. I'm probably too tired to
mention this but: how about creating state_activations with state objects as
ctor parameters?

Regards // Johan