A new start. Questions about PPLs in AF

[CaseyLamers1]

I am starting a new version of my particle accelerator project and I am thinking about converting to PPLs.

The motivation is to have more modular code and lighter exe's.

Some concerns I have are:

I have some classes that are "interface" classes that live on both the PC and RT targets (Pharlap and VXWorks). I believe I need separate PPLs for each OS. I am imagining VX-Actor1, PC-Actor1, Pharlap-Actor1, etc, etc.

I use the Linked Network Actor (LNA) to send messages from the PC to the RT. A lot of the messages are classes that I would want to convert to PPLs too. If I send a class from a PPL on one target and converted to a string for the LNA and the receiving network stream converts it back to a class will there be a name issue if they are in differently named PPLs

I use a lot of object composition (classes with classes as private data). I am worried about managing these dependencies. How do I make sure I don't have more than one copy in memory? A lot of the composition also has hierarchy.

A short example: Actor A contains Class 1. Actor B inherits from Actor A and stores a child of Class 1 (Class 2) in the parent (Actor A) private data. Actor C does the same thing with Class 3 being stored in the parent private data. I don't want multiple copies of Actor A, or Class 1. I want everything pointing to one instance.

Any thoughts are welcome.

Thanks,

Casey

[jon_mcbee]

Hi Casey,

It sounds like you have two main concerns; PPLs across mutliple targets, and scoping of classes in PPLs.  I haven't done work with PPLs across multiple targets and I haven't used the LNA so I don't know the answer to that question (but I am interested in learning). 

There are a few principles that will help you with the second concern though here is a link.  In short, you don't want one PPL per class, you want to group classes into PPL's in as logical a way as possible; i.e. classes that change together are packed together (think OCP), classes that are used together are packed together (think SRP), the granularity of what goes into a package should map to the granularity of what is needed to use the package (think ISP).  Turning the entire Actor Framework into one package fits these principles nicely, as an example.  Turning every message class into a PPL does not fit these principles.

The real value add from following these principles will be the lowered maintenance on your end, and the tooling you will need to create to manage your dependencies. 

Does any of that help?

[CaseyLamers1]

That does help.

In my example above it seems like Actor A and Class 1 would be a logical PPL such that Actor B and Class 2 would depend on that PPL.

I was thinking about Actor A being a PPL and Class 1 being a PPL and potential problems where Actor A depends on Class 1 and then Actor B depends on Actor A and Class 1. Now there are two dependencies on Class 1 and I want Class 1 to be unique.

[jon_mcbee]

If in your example Acctor B and Class 2 are always used with Actor A and Class 1 then it would be beneficial to place them in the same PPL, just depends on how things are used.

I was thinking about Actor A being a PPL and Class 1 being a PPL and potential problems where Actor A depends on Class 1 and then Actor B depends on Actor A and Class 1. Now there are two dependencies on Class 1 and I want Class 1 to be unique.

As long as you turn Class 1 into a PPL, and use the PPL version in the class data for Actor A, you will only have one copy of Class 1 in memory and it will be the PPL version.  It will mean that Actors B and C will depend on the Class 1 PPL, but that is fine.  If Actors A, B, and C are each their own PPLs and you change Class 1, you will  need to rebuild Class 1's PPL, and then rebuild Actors A, B, and C's PPLs as well.  Sticking them all inside one component will save you that trouble.

[dsavir]

Hi,

I put each actor and its messages in one PPL. I also put any shared components in different PPLs, so I had say actor framework ppl, and then Module PPL that inherits from actor framewordk, and some actors A, B, C etc. that inherit from module PPL. As Module PPL had some generic messages (packed with module ppl) I almost didn't have to implement messages for actor A,B,C. In addition, I had a Shared PPL with utilities etc, any actor that needed it used the Shared PPL.

Keep in mind that this can get annoying to debug, as if e.g. the graph isn't updating in Actor A, you can't enter any VI that is from Module PPL or Shared PPL. Obviously, you debug as much as you can before compiling, but that doesn't always work out as well as you wish. On the other hand, once it's working reasonably well it's convenient to have it as a package. I was also using PPLs as plug-ins, so that made it even easier.

Good luck!

Danielle