Understanding the AF

[StevenHowell_XOM]

I am working on a project and just started using the AF. It took me a little while to wrap my head around it, but I think I have it now.

The Actor Core.vi has a QMH embedded into it, and instead of a standard state machine or additional states in a QMH, you created Nested Actors to represent those states and state transitions, which are then called by methods in the Caller Actor?

Do I understand that correctly? The states are abstracted out into Actors, creating an extendable QMH?

-Steven

[CaseyLamers1]

Stephen,

Welcome to AF.

I generally calculate and store state within one of my actors. I use nested actors when I want to build up something. For instance I have a subsystem made up of components. The subsystem is an actor. It launcher the components as nested actors.

The subsystem receives data from the components according to their required interface.

The components may have a state or they may just provide data and perform specific functions.

So I would propose that the actors can have state rather than the actors each being a state.

I would pay particular attention to designing the interface to your actors. What are their public methods and messages that they receive and send. I would also design using the zero coupling methodology for your messages that get sent out from your actors.

Good luck.

Casey

[MattP]

Close.

If you like, the loop with the case structure from your QMH is the Actor, the individual cases of the case structure are your Messages associated with that Actor.  The Actor can send messages to itself or other Actors can send messages to it if they have the reference to the Actor's enqueuer (aka mailbox, aka queue). 

The Actor encompasses the QMH, the set of messages associated with that Actor define its API.

What you describe is more like a State Pattern implementation: https://decibel.ni.com/content/thread/15069  This is a creative way to leverage the Actor Framework, but is by no means a required way of doing so.

[AristosQueue (NI)]

To follow on to Matt's comment: "nested actors" are *separate* QMHs that perform subtasks on behalf of the caller actor. A root actor might be in charge of an entire application, with nested actors handling various subroutines -- data acquisition, user interface interaction, etc.

[StevenHowell_XOM]

Thank you everyone for the information and feedback, I appreciate it. I am enjoying working with the AF. It provides a very elegant solution.