JDP Science Tools

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor private data

Solved!
Go to solution

I have been using async processes for a long time, using my own brew framework with only limited functionality. For some reason I only recently found out about the JDP messenger library and I am learning to implement it.

 

At risk of asking a really dumb question, I really do wonder why the class is not being used to store the Actor's private data. Like so:

aartjan_0-1670505989101.png

I fully understand that the data doesn't need the protection, as there are no traditional methods to operate on the data. It just seems to me as cleaner code. Is there a reason why this won't work or be a bad idea?

 

------------------------------------------------------------------------------------
Seriously concerned about the Labview subscription model
0 Kudos
Message 1 of 2
(1,212 Views)
Solution
Accepted by topic author aartjan

That is a good question.   The short answer is that the "actor" object is already serving as the address of the actor, used externally to send the actor messages, and it is at best awkward to try and make it do double-duty as the actor's internal state data.

 

A longer answer compares Messenger Library with the Actor Framework.  The AF uses its "Actor" object as internal actor data, as you suggest, but it does so at the expense of not being able to use the actor object as an address.  Instead it uses an "Enqueuer" that is the same type for every Actor.  This means you can't write messaging subVIs that only accept the address of a certain type of Actor, and can easily wire up the wrong Enqueuer.  In contrast, in Messenger Library one can write such subVIs; an example of which is the "Metronome" utility actor that come with the Library:

2022-12-09 09_00_05-Metronome.lvclass on Main Application Instance.png

Here I have two actor methods that are used to interact with the Metronome.  Because the inputs/outputs are of type "Metronome" it is impossible to miswire a different actor's address.

 

If you had the actor object do double-duty as internal data, with internal methods, it would get very confusing, at least.

 

Note that you can use an object for actor internal data, but I recommend you use a different class for it.  I often have what I call a "Driver" class in an actor to do the "heavy lifting" of handling whatever the actor is responsible for (for example, a "Furnace" actor might have a "PID Controller" driver class).  

Message 2 of 2
(1,180 Views)