NAME¶
POE::NFA - an event-driven state machine (nondeterministic finite automaton)
SYNOPSIS¶
use POE::Kernel;
use POE::NFA;
use POE::Wheel::ReadLine;
# Spawn an NFA and enter its initial state.
POE::NFA->spawn(
inline_states => {
initial => {
setup => \&setup_stuff,
},
state_login => {
on_entry => \&login_prompt,
on_input => \&save_login,
},
state_password => {
on_entry => \&password_prompt,
on_input => \&check_password,
},
state_cmd => {
on_entry => \&command_prompt,
on_input => \&handle_command,
},
},
)->goto_state(initial => "setup");
POE::Kernel->run();
exit;
sub setup_stuff {
$_[RUNSTATE]{io} = POE::Wheel::ReadLine->new(
InputEvent => 'on_input',
);
$_[MACHINE]->goto_state(state_login => "on_entry");
}
sub login_prompt { $_[RUNSTATE]{io}->get('Login: '); }
sub save_login {
$_[RUNSTATE]{login} = $_[ARG0];
$_[MACHINE]->goto_state(state_password => "on_entry");
}
sub password_prompt { $_[RUNSTATE]{io}->get('Password: '); }
sub check_password {
if ($_[RUNSTATE]{login} eq $_[ARG0]) {
$_[MACHINE]->goto_state(state_cmd => "on_entry");
}
else {
$_[MACHINE]->goto_state(state_login => "on_entry");
}
}
sub command_prompt { $_[RUNSTATE]{io}->get('Cmd: '); }
sub handle_command {
$_[RUNSTATE]{io}->put(" <<$_[ARG0]>>");
if ($_[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {
$_[RUNSTATE]{io}->put('Bye!');
$_[MACHINE]->stop();
}
else {
$_[MACHINE]->goto_state(state_cmd => "on_entry");
}
}
DESCRIPTION¶
POE::NFA implements a different kind of POE session: A non-deterministic finite
automaton. Let's break that down.
A finite automaton is a state machine with a bounded number of states and
transitions. Technically, POE::NFA objects may modify themselves at run time,
so they aren't really "finite". Run-time modification isn't
currently supported by the API, so plausible deniability is maintained!
Deterministic state machines are ones where all possible transitions are known
at compile time. POE::NFA is "non-deterministic" because transitions
may change based on run-time conditions.
But more simply, POE::NFA is like POE::Session but with banks of event handlers
that may be swapped according to the session's run-time state. Consider the
SYNOPSIS example, which has "on_entry" and "on_input"
handlers that do different things depending on the run-time state.
POE::Wheel::ReadLine throws "on_input", but different things happen
depending whether the session is in its "login",
"password" or "command" state.
POE::NFA borrows heavily from POE::Session, so this document will only discuss
the differences. Please see POE::Session for things which are similar.
PUBLIC METHODS¶
This document mainly focuses on the differences from POE::Session.
get_current_state¶
Each machine state has a name.
get_current_state() returns the name of
the machine's current state.
get_current_state() is mainly used to
retrieve the state of some other machine. It's easier (and faster) to use
$_[STATE] in a machine's own event handlers.
get_runstate¶
get_runstate() returns the machine's current runstate. Runstates are
equivalent to POE::Session HEAPs, so this method does pretty much the same as
POE::Session's
get_heap(). It's easier (and faster) to use $_[RUNSTATE]
in a machine's own event handlers, however.
spawn STATE_NAME => HANDLERS_HASHREF[, ...]¶
spawn() is POE::NFA's constructor. The name reflects the idea that new
state machines are spawned like threads or processes rather than instantiated
like objects.
The machine itself is defined as a list of state names and hashes that map
events to handlers within each state.
my %states = (
state_1 => {
event_1 => \&handler_1,
event_2 => \&handler_2,
},
state_2 => {
event_1 => \&handler_3,
event_2 => \&handler_4,
},
);
A single event may be handled by many states. The proper handler will be called
depending on the machine's current state. For example, if "event_1"
is dispatched while the machine is in "state_2", then
handler_3() will be called to handle the event. The state -> event
-> handler map looks like this:
$machine{state_2}{event_1} = \&handler_3;
Instead of "inline_states", "object_states" or
"package_states" may be used. These map the events of a state to an
object or package method respectively.
object_states => {
state_1 => [
$object_1 => [qw(event_1 event_2)],
],
state_2 => [
$object_2 => {
event_1 => method_1,
event_2 => method_2,
}
]
}
In the example above, in the case of "event_1" coming in while the
machine is in "state_1", method "event_1" will be called
on $object_1. If the machine is in "state_2", method
"method_1" will be called on $object_2.
"package_states" is very similar, but instead of using an $object, you
pass in a "Package::Name"
The "runstate" parameter allows "RUNSTATE" to be initialized
differently at instantiation time. "RUNSTATE", like heaps, are
usually anonymous hashrefs, but "runstate" may set them to be array
references or even objects.
State transitions are not necessarily executed immediately by default. Rather,
they are placed in POEs event queue behind any currently pending events.
Enabling the "immediate" option causes state transitions to occur
immediately, regardless of any queued events.
goto_state NEW_STATE[, ENTRY_EVENT[, EVENT_ARGS]]¶
goto_state() puts the machine into a new state. If an ENTRY_EVENT is
specified, then that event will be dispatched after the machine enters the new
state. EVENT_ARGS, if included, will be passed to the entry event's handler
via "ARG0..$#_".
# Switch to the next state.
$_[MACHINE]->goto_state( 'next_state' );
# Switch to the next state, and call a specific entry point.
$_[MACHINE]->goto_state( 'next_state', 'entry_event' );
# Switch to the next state; call an entry point with some values.
$_[MACHINE]->goto_state( 'next_state', 'entry_event', @parameters );
stop¶
stop() forces a machine to stop. The machine will also stop gracefully if
it runs out of things to do, just like POE::Session.
stop() is heavy-handed. It will force resources to be cleaned up.
However, circular references in the machine's "RUNSTATE" are not
POE's responsibility and may cause memory leaks.
$_[MACHINE]->stop();
call_state RETURN_EVENT, NEW_STATE[, ENTRY_EVENT[, EVENT_ARGS]]¶
call_state() is similar to
goto_state(), but it pushes the current
state on a stack. At some later point, a handler can call
return_state() to pop the call stack and return the machine to its old
state. At that point, a "RETURN_EVENT" will be posted to notify the
old state of the return.
$machine->call_state( 'return_here', 'new_state', 'entry_event' );
As with
goto_state(), "ENTRY_EVENT" is the event that will be
emitted once the machine enters its new state. "ENTRY_ARGS" are
parameters passed to the "ENTRY_EVENT" handler via
"ARG0..$#_".
return_state [RETURN_ARGS]¶
return_state() returns to the most recent state in which
call_state() was invoked. If the preceding
call_state() included
a return event then its handler will be invoked along with some optional
"RETURN_ARGS". The "RETURN_ARGS" will be passed to the
return handler via "ARG0..$#_".
$_[MACHINE]->return_state( 'success', @success_values );
Methods that match POE::Session¶
The following methods behave identically to the ones in POE::Session.
- ID
- option
- postback
- callback
About new() and create()¶
POE::NFA's constructor is
spawn(), not
new() or
create().
PREDEFINED EVENT FIELDS¶
POE::NFA's predefined event fields are the same as POE::Session's with the
following three exceptions.
MACHINE¶
"MACHINE" is equivalent to Session's "SESSION" field. It
holds a reference to the current state machine, and is useful for calling its
methods.
See POE::Session's "SESSION" field for more information.
$_[MACHINE]->goto_state( $next_state, $next_state_entry_event );
RUNSTATE¶
"RUNSTATE" is equivalent to Session's "HEAP" field. It holds
an anonymous hash reference which POE is guaranteed not to touch. Data stored
in "RUNSTATE" will persist between handler invocations.
STATE¶
"STATE" contains the name of the machine's current state. It is not
equivalent to anything from POE::Session.
EVENT¶
"EVENT" is equivalent to Session's "STATE" field. It holds
the name of the event which invoked the current handler. See POE::Session's
"STATE" field for more information.
PREDEFINED EVENT NAMES¶
POE::NFA defines four events of its own. These events are used internally and
may not be overridden by application code.
See POE::Session's "PREDEFINED EVENT NAMES" section for more
information about other predefined events.
The events are: "poe_nfa_goto_state", "poe_nfa_push_state",
"poe_nfa_pop_state", "poe_nfa_stop".
Yes, all the internal events begin with "poe_nfa_". More may be
forthcoming, but they will always begin the same way. Therefore please do not
define events beginning with "poe_nfa_".
SEE ALSO¶
Many of POE::NFA's features are taken directly from POE::Session. Please see
POE::Session for more information.
The SEE ALSO section in POE contains a table of contents covering the entire POE
distribution.
BUGS¶
See POE::Session's documentation.
POE::NFA is not as feature-complete as POE::Session. Your feedback is
appreciated.
AUTHORS & COPYRIGHTS¶
Please see POE for more information about authors and contributors.