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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-28 02:19:09

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:loom.20040527T133057-890_at_post.gmane.org...
> Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:
>
> > What's stopping me from always create them in constructor/delete in
> > destructor, then just init/deinit them (if necessary) in entry/exit?
>
> The fact that most classes (well-designed ones) don't have init/deinit.
>

I'm totally aware of the RAII idom and didn't literally mean that the
classes had init/deinit methods which would
totally initialize and clean up the state. I referred to actions
(_manipulating_ already created members: classes/pods/built-ins) that
_might_ be necessary to call depending on the state in question.

Ideally a state should be state-less, right? Once created it should always
be able to execute the same actions no matter when in time. IRL there's more
likely something that needs to be done to initiate the state. Does it matter
if this is a two-step procedure:

Allocate in constructors + Initialize in entry

or one-step:

Allocate and initialize in constructor.

Non-trivial states will doubtlessly need to perform at least some amount of
actions that are not simply construct their members. If you by providing
explicit entry()/exit() actions (which can be _guaranteed_ to be called
using RAII AFAIK) you're also encouraging the users of the library to
separate resource acquisition from resource init: this also enables
policy-based state lifetimes. If users have no need for entry / exit
actions - they could be made virtual so that users don't need to implement
them. Yes - virtual calls are comparatively expensive; maybe this could be
fixed using some template meta-programming magic, explicit policies or
whatever. I don't know - I'm just a potential library user ;-).

Thinking about it there's (at least) one technical argument agains mapping
entry/exit to constructor/destructor calls - restrictions on calling virtual
member functions. Is this a 'hard' technical argument of not ... depends on
your point of view. For me personally the semantics of explicit entry/exit
methods is (at least) equally important.

[... snip ...]

> > In terms of speed, I've got no real opinions (so far). I guess it
depends on
> > whatever fits the particular application in question - another reason
for
> > policy-based state-lifetime management (if possible)?
>
> 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
;-)

>
> > > - Nobody has so far presented hard technical facts that support the
view
> > > that mapping entry/exit to ctor/dtor is wrong.

See at least the restriction I mention above.

> >
> > <philosophical entry/>
> > For me, hard technical facts aren't everything. All software engineering
is
> > an art and a craft as well, IMHO. Should one always choose a particular
> > design on hard technical facts only, or should you also trust your
gut-level
> > feelings (open question)?
> > </philosophical entry>
>
> To me good design is 10% ideas, imagination and, yes, gut-level feelings.

Gut-level feelings are there all the time during development; refactoring;
recognizing "code smells"; ... I think it amounts to much more than 10% of
the time you spend implementing (aka low-level designing) your library.

> The
> other 90% are technical facts. I believe the initial effort when crafting
an
> interface is always gut-based, afterwards comes the long and tedious
period of
> verifying (with hard facts) that your gut feelings are right. If there are
no
> hard facts to justify a feature then I unceremoniously throw it out. Not
doing
> so means overloading an interface and elevating the risk of overwhelming
> potential users with unnecessary baggage.
>

A bit off-topic perhaps, but Ruby (the language) frequently "overloads"
methods with multiple names - makes more users think that the interface is
intuitive. Not saying that we should do it in C++ (bloated interfaces are ge
nerally bad), but it's worth thinking about.

Regards // Johan