Re: [boost] Proposal to add a Boost.FSM library

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2007-01-03 15:45:15

Andrey Semashev wrote:
> Wednesday, January 3, 2007, 9:46:16 PM, you wrote:
> 
> > It would return variant<State1&, State2&, /* ... */ >. Visual
> > representation of FSM would be fuzzy but it still better than no
> > visual representation at all.
> 
> The "variant" has a limited set of possible types 

So does any state machine - it has a limited set of types ;-)

> and it takes some time
> to dispatch the real type of the object it stores.
It a resonable price for the flexibility.

> Besides, I'd like to
> keep the ability to return something useful for the user from
> "on_process".

IMO, it doesn't outweight an ability to have a transition table
available at compile-time.

> IMHO, transition maps exist to make FSM transitions visible at the
> first glance. No need to involve event handlers into this and take
> away several useful features by this, such as return values and template
> event handlers, and add these "id< ... >" arguments on top of that.

An ability to define one function for transitions from several states is
more important than template handlers.

I agree that id<...> is not convinient. I'd be happy to get rid of it.

> Actually, it's the way Boost.FSM is implemented except that it doesn't
> allow to access one state from another and therefore ensures
> encapsulation.

I couldn't build a sample program neither on gcc 3.4.6 nor on Intel
Linux 8.1 so I can only guess that dynamic_cast<OtherState*>(this) would
access OtherState from *this state.

-- 
Alexander Nasonov
http://nasonov.blogspot.com
Nothing is more obstinate than a fashionable consensus. -- Margaret
Thatcher --
This quote is generated by: 
	/usr/pkg/bin/curl -L http://tinyurl.com/veusy         \
	  | sed -e 's/^document\.write(.//' -e 's/.);$/ --/'  \
	        -e 's/<[^>]*>//g' -e 's/^More quotes from //' \
	  | fmt | tee ~/.signature-quote