Feedback on my attempts at the actor framework

[remywizard]

Hi everyone,

I have been trying to learn the actor framework and how to do it with a plugin type architecture and use zero coupling. I created a calculator application that sort of started with the tutorial that DMurrayIRL put together (thanks DMurrayIRL for the tutorial!). Anyway, I tried to use the factory pattern to load actor plugins based on existing in a directory. I also had them interface with an abstract message class. If you guys have time I would appreciate any feedback you can give me. I may have some concepts wrong or doing something that isn't the standard conventional way and I would like to know this now before I start making more applications that follow this same methodology. If things are legit hopefully other can use it to learn about the framework. The code was produced in LabVIEW 2015. I attached a 2014 version for those who haven't upgraded yet. Thanks!

Message was edited by: remy240 - Added V2 files that contain suggestions from Casey and Danielle

[dsavir]

Very nice!

I liked the abstract messages and use of events, and the loading of the plugins and messages.

Some comments:

1. I would do is have all the plugin classes inherit from a Plugin Actor in the same way that the messages inherit form the calculate values message class.

2. I found the dependencies confusing: The abstract message is in the calculator lvlib, so using the abstract message as a parent in the plugins pulls the calculator class into the plugin. For the same reason, perhaps use an abstract message also for the messages to the calculator, because otherwise the calculator is a dependency of the plugin. Did you try to compile this? I think it would cause you some problems.

Good luck,

Danielle

[remywizard]

Thank you for the feedback!

dsavir wrote:

1. I would do is have all the plugin classes inherit from a Plugin Actor in the same way that the messages inherit form the calculate values message class.

This is a good idea I will implement this.

dsavir wrote:

2. I found the dependencies confusing: The abstract message is in the calculator lvlib, so using the abstract message as a parent in the plugins pulls the calculator class into the plugin. For the same reason, perhaps use an abstract message also for the messages to the calculator, because otherwise the calculator is a dependency of the plugin. Did you try to compile this? I think it would cause you some problems.

I did start to complie this and I actually just started running into the problem you describe. My plugins don't work because they can't find the calculator Update Result Event Msg. I will try to make an abstract class for these messages too.

Should the abstract messages be in their own lvlib instead of the calculator lvlib? Would that solve the problem of the plugins pulling the calculator class into them?

[CaseyLamers1]

A couple of things I might do...

Instead of building the ring of calculation tupes by using the class names I would provide a message from the calculations to the calculator of "Calculation Name" and have each calculation reply when launched.

I would create an abstract message "Result Msg" class and have store it in the class private data of the calculations and then the launcher (calculator) should provide a child of the message (like your "Update Result Event Msg") that gets the data out of the Result Msg.lvclass and fires an event. This would remove the dependency on the Update Result Event Msg from the plug-ins.

You might have a parent of the calculations that could store the Result Msg and when you launch the calculations you cast them to that "Parent Calculation" type and write the "Update Result Event Msg" for your calculator to each calculation.

User events are good for updating the UIs, but messages are good for going between actors.

Run your error wires through subVIs with Error in/out.

A good start. A little more module independence will make it better.

Casey

[remywizard]

Thanks for the feedback. These are all great ideas! I will work on implementing them.

If I have the calculations send a message back to the Calculator when launched I am thinking this message should also be an abstract message? Similar to how you propose "Result Msg" works, correct?

[CaseyLamers1]

Yes, use the same abstract message pattern.

In general when I send a message to an actor's caller I always use the abstract message/child message provided by callee pattern.

Nested actors don't know who they are replying to.

[remywizard]

I added a new version of the code that contains the suggestions I have received from Casey and Danielle. I added the files in addition to the original ones so people could see the progression of the code. When I was trying to learn the framework I was trying to find examples like that.

Casey, The only thing I haven't implemented was having the calculations reply when launched with their name. I am struggling trying to figure out how best to implement this. When messaging back with their name how do I pair that up with the correct actor and message it goes with? Should the calculations also send back their message type with the name, or leave the calculator building the array of message types the way it currently is? Or do I keep an array of calculation types in the private data of the calculator and the message to the calculator will update this array?

[CaseyLamers1]

I see the issue.

I guess you would need to wait for the reply and build an array of names that the index of the array is equal to the index of the enqueuer to send the message to. When you select a calculation type it sends determines the index of the message and then puts the message on the correct enqueuer.

That is one way at least.

[CaseyLamers1]

I usually just use the Enqueue method like this:

Create a data accessor for the parent to write the data. Send it to the caller. I made this edit in your addition calculation, and you would do the same for each reply to the parent. No need for putting the enqueue in a subVI.

[LGallegos_]

Now that you have the Generic Calculation class, can't you create a dynamic dispatch VI for your addition, subtraction, divide, and multiply class to override? This new VI could take the place of Addition Calculation vi, Subtraction Calculation vi, Divide Calcuation vi, and Multiply Calculation vi. This would reduce the number of Msg classes you have, since you'll only need one for Generic Calculation's new dynamic dispatch vi instead of one for each Calculation vi.