AS3 API for TryHarderStateMachine

A) StateConfiguration.as

 fsm
    .configureState( StateNames.HAPPINESS )
    .withEntryGuards( OnlyIfHappy, OnlyIfSmiling )
    .withExitiGuards( OnlyIfAnxious )
    .withTargets( StateNames.SADNESS, StateNames.ECSTACY );

B) ProcessConfiguration.as

 fsm
    .configure( ProcessNames.GET_HAPPY )

    .ifCurrentState( StateNames.FRUSTRATED )
    .transition( StateNames.ANNOYED, StateNames.EXPECTATION )

    .ifCurrentState( StateNames.EXPECTATION )
    .transition( StateNames.EPIPHANY, StateNames.HAPPINESS )
    
    .elseThrowError();

C) MappingProcessesToEvents.as

 fsm.mapProcess( ProcessNames.GET_HAPPY )
   .to( HappyEvent.GET_HAPPY )
   .unlock( StateNames.EXPECTATION ).after( HappyEventTrigger );

D) MappingCommandsToState.as

 fsm
      .during( StateNames.HAPPINESS)
      .cancellation
      .always.execute( DoThis, DoThat ).onApproval( OnlyIfThat )
      .and.always.execute( DoTheOther )

 fsm
      .during( StateNames.HAPPINESS)
      .tearDown
      .always.execute( DoThisCmd ).onApproval( OnlyIfThis ) // executed only if all guards approve
      .and.always.execute( DoThatCmd ).onApproval( OnlyIfThat ) // executed only if all guards approve
      .and.always.execute( DoTheOther ) //always executed;

 fsm
      .during( StateNames.HAPPINESS )
      .cancellation
      .either.execute( DoThis, DoThat ).onApproval( OnlyIfThat )  // executed only if all guards approve
      .or.execute( DoTheOther )  // executed only if previous commands are not executed
      .and.always.execute( SomethingElse) // always executed



 

States (nodes)

• are defined with Strings to allow creation and distribution to be managed internally, and to keep application code agnostic.
• have entered, teardown and cancelled phases that are dispatched via the event bus.
• can have entering and exiting guards to modify / restrict access.
• have transitions (edges) defined by declaring legal target states.

Processes

• these are how application code communicates with the FSM (via ProcessEvents).
• they define a series of transitions from state to state.
• on configuration the Processes' State to State paths will be validated against the States' declared targets.
• various outcomes can be defined depending on the currentState (either a progression of transitions, or an error being thrown)
• transitions from State to State are always synchronous.
• a Process can be locked at any State along its defined transition path to encapsulate asynchronousity. Once unlocked the Process will continue along its transition path.
• a locked process can be unlocked by any event specified by the untilEvent() method
• if a Process is locked that entire instance of the FSM is locked, and no other Process can be run, until it is unlocked.
• a Process may also be deadLocked, which is essentially the same as lock, but throws an error if an attempt is made to advance the FSM without first unlocking.
• if a transition is canceled by a State's Guards then the Process is flushed and the FSM reset.
• if a Process is already running when a Process is run, the running Process will be flushed in favour of the new one (unless the Process is locked).

Command Mapping

• multiple Commands may be mapped for each State's phase.
• multiple Guards may be mapped to each Command mapping.
• I like the idea of being able to group guarded Commands into 'or' groups. If no Commands are executed inthe first group, then the next group is attempted. Needs more thinking through.
• a very important concept is that transitions between states are always synchronous. Therefore Commands are executed in parallel. Asynchronous behaviour is dealt with by locking a Process, then unlocking on callback.

Very interesting... It would be great to see a basic implementation example to see how it stacks up against the traditional FSM approach.

cheers... am working one up in tandem as a robotlegs 2 extension

Cool... looking forward to taking a look when you're done.

maybe a while, got a full plate at the mo :)

yeah no worries mate, I know the feeling...