Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
POE::NFA(3)	      User Contributed Perl Documentation	   POE::NFA(3)

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.

perl v5.24.1			  2015-06-03			   POE::NFA(3)

NAME | SYNOPSIS | DESCRIPTION | PUBLIC METHODS | PREDEFINED EVENT FIELDS | PREDEFINED EVENT NAMES | SEE ALSO | BUGS | AUTHORS & COPYRIGHTS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=POE::NFA&sektion=3&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help