Greets!
On Sat, 30 Dec 2000 05:13:10 +0100, Torvald Riegel wrote:
>
>I'd like to know wether one should return the machine's reference to spawn()'s
>caller or just use it to put the machine into its first state. Not returning
>the reference and handling externally forced state transitions by poe_nfa_
>messages is probably cleaner. but you would need a predefined start
>state/event to make this complete.
POE::NFA is still very young. It doesn't even have tests. That said,
I haven't established any conventions for using it. "Whatever works
best for you and your program" seems to be a good rule of thumb.
I try to avoid returning and using references to POE::Session and
POE::NFA directly. A lot of POE's housekeeping relies on deterministic
object destruction, and holding extra references to Session and NFA
causes their instances not to DESTROY when Kernel expects them to.
You'd need at least one (possibly more, depending on runtime modes:
say active vs. passive FTP, for example) start state/event to make
it work. I've always assumed that spawning a new machine would also
start it up.
>another thing: is there a way to directly call a state's event handler
>without using invoke_state directly? although the docs say goto_state calls
>the specified event's handler, the code looks like a state transitions
>is being posted.
State transitions (and input events) are posted through Kernel's queue
to avoid race conditions. Otherwise it would be easy to post some
events for the current state and then switch away from the state before
they were dispatched. This makes sure events posted before a transition
are dispatched before the transition is made.
You could call an event handler directly, but you'd have to make sure
you passed all the right parameters to it. If you need a chunk of code
that's visible as an event handler and also as a plain perl function,
maybe you can extract it to a common function that's called from an
event handler and from someplace else.
>a callable handler returning the machine's current state could be useful too.
>(as machines are supposed to stop after processing their input, the owner
>could check which stop state it is in or how it is progressing)
That sounds useful. NFA will pass a C<STATE> parameter to event
handlers in 0.1204. C<STATE> will contain the current state's name.
NFA will also have a get_current_state() method in case something
external needs to know.
>what about a possibility to define handlers common to all states? one could
>use that for the handler above or to handle _stop events (they'd need to
>be posted, too) and postback the machine's stop state.
You'd defined the handler as a named sub and then refer to it from all
the states. That could get tedious, though. Actually, you wouldn't
post a _stop event at an NFA instance to stop it, you'd just call its
stop() method.
But yeah, it would be handy if event handlers could be marked "global"
and available from every state. It would be even better if the
mechanism could be a little more selective, letting some states inherit
certain handlers and others inherit others.
I haven't used NFA much yet, so I'm at a loss for specifics. Does
anyone have suggestions?
>and i'd be interested in how other users think about some kind of error
>handling / result posting guidelines. up to now giving commands is similar
>among the components. returning values doesn't seem to.
Me too!
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
