David Abrahams wrote:
> > I'm reading it like a bible only when it helps to argue my case ;-).
> 
>  I know there's a smiley, but you're not doing your credibility any
>  favors with that statement.  It makes me wonder how many other
>  decisions in the design have such a flimsy foundation.

I think a foundation for a decision is not flimsy when the behavior in
question has proved to be useful in practice. So far nobody, who seems to
have experience with non-trivial FSMs, has doubted that it is useful to
terminate a state machine when it is destructed (my assumption A1).
BTW, as pointed out by someone else the user *does* have a choice. If she
happens to have an exit action that she'd rather not have executed upon
destruction then she can always transform the machine part in question such
that her action is executed as part of a transition action instead (I would
consider it a design error not to do so). Every Moore machine (an FSM that
has only entry and exit actions) can be transformed to a Mealy machine (an
FSM that has only transition actions) and vice versa.

>  If you want to convince _me_ (I'm not saying that's important or
>  anything), you're going to have to make the case for why an FSM object
>  should make transitions (or state changes, if you like) when it is
>  destroyed. To me it seems like there are very obvious use cases
>  supporting the argument that it should *not* happen.

As pointed out above, you *can* implement your FSM in a way such that no
action is ever executed upon destruction. Whether such a machine is
typically well-designed is an altogether different question (I'm not saying
that such a machine is always badly designed).

State machines do have a theoretical/mathematical background. Despite this
background, I need to make some assumptions when I model them in C++. I
strongly believe that not making such assumptions would have lead to an
interface that is more complex than necessary for most real-world
applications. For one in X applications an assumption could well turn out to
be wrong and the application needs to resort to work-arounds as a result (as
outlined above). To me, said assumption is justified if X turns out to be
sufficiently high.

The assumptions are based on practical experience, which is of course not
provable. Since you seem to accept only strictly provable arguments, I will
never be able to convince you.

>  Furthermore, it
>  seems as though, if you want that behavior, it's trivial to get it by
>  wrapping the FSM in a derived class whose destructor finalizes the
>  state machine.

Yes, but only at the cost of making the current interface (and
implementation) more complex (we'd need to have at least a separate exit()
function, right?).

Regards,

Andreas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost