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().

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.