ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> boost
boost
[boost] Re: [prereview request][fsm]
by David Abrahams other posts by this author
May 31 2004 4:06PM messages near this date
[boost] Re: [prereview request][fsm] | [boost] Re: [prereview request][fsm]
"Andreas Huber" <ah2003@[...].net>  writes:

> > I said long ago that I was going to stop poking at this one, and
> > didn't, because I had the sense that issues in this area, and the way
> > you were reacting to my poking, might indicate that there were other
> > problems.
> 
>  I can only guess what exactly you mean with this, but it does sound
>  like an accusation of me somehow evading your questions, see below.

That was not my intention.  

It did seem to me that when several people have said "this aspect of
the design seems to complicate things for too little advantage", your
reaction was to defend it ever more vigorously, declaring yourself to
have "proven" things that seemed to me far from well-founded, and with
not very much consideration given to the opposing arguments -- in fact
IIRC you said that *no* technical reasoning against the design choice
had been given, when I definitely made some techinical arguments.  It
made me concerned that similar self-justifying thought-processes had
gone into other design decisions.

> > I don't feel as though much progress has been made, and you seem to
> > feel that trying to convince me of anything by example is futile.
> 
>  I did provide one example many posts ago (the pump in the
>  dishwasher). 

Ah, yes; I think that was before I was paying much attention.

>  Also, let me quote what you had to say about this in
>  another post:
> 
>  David Abrahams wrote:
> >> 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).
> >
> > I don't doubt that it's often useful.  I also think it is surely
> > sometimes highly undesirable.  If you remove A1, the "useful" behavior
> > is trivial to achieve without transforming the FSM, so it seems that a
> > design without A1 is both more flexible and more orthogonal.
> 
>  Since you don't doubt that it's often useful, why exactly should I then
>  provide further examples in support for it? They will surely not convince
>  that your "sometimes highly undesirable" assertion is invalid (that would
>  seem highly illogical). 

Good point.

>  BTW, I don't think that it is completely invalid either. What this
>  all really boils down to is an interface that is easy to use and
>  works well for the vast majority of the use-cases and requires
>  workarounds for a minority of the use cases. I insisted on an
>  example also to show how simple those workarounds can be and I doubt
>  that they can typically even be called workarounds as they don't
>  make machine design worse in any way
                            ^^^^^^^^^^

This is the kind of argumentation I'm talking about.  Having to repeat
the would-be exit action in all outgoing transitions *is* worse in
some ways.  Duplication of code or logic is evil.

The choice is between having to call the FSM's terminate once, in some
controlling scope (e.g. derived class destructor) when you want it, or
having to apply a workaround that affects _all_ transitions from _all_
states whose exit actions might fail, or shouldn't run from the FSM's
destructor.  It seems like a poor design trade-off to me... but didn't
I say I was done trying to make points here?  ;-)

>   (especially not with Darryl's trick).

I don't understand it, FWIW.

> > So really, now I'm going to stop worrying this issue.  May
> > other peoples' posts be more helpful than mine have been!
> 
>  Having slept over this and having spent pretty much the whole
>  morning rereading our posts and reflecting on this whole discussion,
>  I'm a bit at a loss what exactly went wrong. While I tried to always
>  give accurate and to-the-point answers, you seem to have
>  misunderstood them too often, what culminated in your accusation of
>  me reasoning circularily. I don't want to imply that the problem
>  necessarily lies on your side. In the beginning I definitely made
>  the mistake that I assumed too often on what we would agree and what
>  not. However, this alone couldn't possibly have led to the situation
>  we now have. I don't have much of a clue what else I have done
>  wrong.

I'm sorry if my post caused you to agonize over this.  You haven't
done anything wrong; there's no crisis.  Sometimes communication
simply fails to be effective.  It's not a big deal.  I need to
disengage from the argument, and thought I should give an explanation.

Cheers,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thread:
Andreas Huber
Andreas Huber
Andreas Huber
Darryl Green
Darryl Green
Darryl Green
Darryl Green
Andreas Huber
E. Gladyshev
Andreas Huber
Andreas Huber
E. Gladyshev
E. Gladyshev
Darryl Green
Andreas Huber
Johan Nilsson
Darryl Green
Andreas Huber
Andreas Huber
Rob Stewart
Andreas Huber
Rob Stewart
Johan Nilsson
Andreas Huber
Andreas Huber
Johan Nilsson
Johan Nilsson
Andreas Huber
Andreas Huber
Andreas Huber
Darryl Green
David Abrahams
Andreas Huber
Andreas Huber
Rob Stewart
Andreas Huber
Andreas Huber
Andreas Huber
Andreas Huber
David Abrahams
David Abrahams
David Abrahams
Andreas Huber
Andreas Huber
Darryl Green
David Bergman
David Abrahams
David Abrahams
David Abrahams
Andreas Huber
Andreas Huber
David Abrahams
Andreas Huber
Andreas Huber
Andreas Huber
Andreas Huber
Darryl Green
Andreas Huber
Robert Bell
David Abrahams
E. Gladyshev
Johan Nilsson
Jeff Flinn
Johan Nilsson
Andreas Huber
Jeff Flinn
E. Gladyshev
Andreas Huber
Andreas Huber
Iain K. Hanson
Robert Bell
David Abrahams
E. Gladyshev
Andreas Huber
Andreas Huber
David B. Held
Andreas Huber
Johan Nilsson
Johan Nilsson
Peter Dimov
Johan Nilsson
Topher Cooper
Johan Nilsson
Johan Nilsson
Andreas Huber
Robert Bell
Andreas Huber
Andreas Huber
Andreas Huber
E. Gladyshev
Andreas Huber
Andreas Huber
E. Gladyshev
E. Gladyshev
Andreas Huber
Andreas Huber
E. Gladyshev
David Abrahams
Andreas Huber
E. Gladyshev
E. Gladyshev
Rob Stewart
E. Gladyshev
E. Gladyshev
Rob Stewart
E. Gladyshev
Rob Stewart
E. Gladyshev
Andreas Huber
Andreas Huber
E. Gladyshev
Marshall Clow
Marshall Clow
E. Gladyshev
David Abrahams
Darryl Green
E. Gladyshev
Andreas Huber
Andreas Huber
Robert Bell
Darryl Green
Pavel Vozenilek
David Abrahams
Andreas Huber
David Abrahams
Gregory Colvin
Pavel Vozenilek
Andreas Huber
Robert Bell
Andreas Huber
Johan Nilsson
Andreas Huber
Andreas Huber
Johan Nilsson
Johan Nilsson
Rob Stewart
Johan Nilsson
Andreas Huber
Andreas Huber
David Abrahams
Andreas Huber
Andreas Huber
David Abrahams
Andreas Huber
Andreas Huber
Johan Nilsson
Rob Stewart
Kwee Heong Tan
David Abrahams
Andreas Huber
David Abrahams
David Abrahams
Andreas Huber
Andreas Huber
Andreas Huber
David Abrahams
Andreas Huber
John Fuller
David Abrahams
David Abrahams
Andreas Huber
Andreas Huber
Aleksey Gurtovoy
David Abrahams
David Abrahams
David Abrahams
Andreas Huber
David Abrahams
David Abrahams

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved