Is my best option for a VIM with a PPL to create a helper library as a friend?

[GregFreeman]

I have a PPL that has a PluginManager class inside it among a bunch of other classes. The PluginManager contains a list of a whole bunch of plugins. 

I want to write a method that gets all plugins from that list that are of a specific type. Think pluginManager.GetPluginsOfType<T>(); So I want that method to be a VIM.

However, I know we can't have VIMs in PPLs. I am thinking my best option is to give my PluginManager class a community scoped accessor to the plugin list, and then make a separate lvlib as a helper. That helper lvlib would be a friend of my PPL so it could access the community getter. I'm not in love with the idea of needing the helper library to get methods that I wish existed on the PluginManager class itself, but I do think it's my only option short of refactoring all my calling code to reference the PluginManager's lvlib instead of the lvlibp. I really don't want to rewind all that work. 

Just wanted to ask if anyone else had other ways to solve this.

[IlluminatedG]

If it's a class input it doesn't need to be a malleable. You can use preserve run-time type and even get the wired type out when you lookup from a map by name or something. You would need to potentially play some tricks during registration with VI server if you wanted all levels of inheritance to retrieve by any ancestor type as well.

[GregFreeman]

---

@IlluminatedG wrote:

If it's a class input it doesn't need to be a malleable. You can use preserve run-time type and even get the wired type out when you lookup from a map by name or something. You would need to potentially play some tricks during registration with VI server if you wanted all levels of inheritance to retrieve by any ancestor type as well.

---

I have tried preserve runtime type without luck, unfortunately. Seems it won't propagate if the input is a single object and then the output is an array of that object type. So, I input a class, use preserve runtime type in a for loop, conditional index on the error, but the output array still is of type LVObject.

There could be multiple plugins of the same base type that I want to grab. 

Edit: didn't see you mentioned a map. Maybe I can try that instead of an array. 

[IlluminatedG]

Ahh right. Yeah PRC won't work if you're returning an array, brain fart there.

[IlluminatedG]

If we NEED a VIM, we just leave it outside the library/PPL being built and just make sure it follows along. We've been opting to do the little bit of conversion needed (either from variants or classes) manually instead of in a VIM because of the issues VIMs present, especially with PPLs. I've started just creating palettes with the merge BD option in VIPM to pre-place the bits needed to do the conversion whether it be the variant to data node or a loop to cast the base class types to the desired type.

Unfortunately it also doesn't seem possible to have the VIM in the same project and just brought along to the support directory when building the PPL so it would need to come from a completely different project that depends on the built PPL and you could do something like a source distribution to "build" the VIM to the same folder the PPL is built to so the link paths get setup as expected from the VIM.

Community scope also tends to be problematic with PPLs. I don't see the need to community scope the VI for getting plugins of type since all the VIM provides overtop of it is the convenience of not casting the classes yourself.

[GregFreeman]

---

@IlluminatedG wrote:

If we NEED a VIM, we just leave it outside the library/PPL being built and just make sure it follows along. We've been opting to do the little bit of conversion needed (either from variants or classes) manually instead of in a VIM because of the issues VIMs present, especially with PPLs. I've started just creating palettes with the merge BD option in VIPM to pre-place the bits needed to do the conversion whether it be the variant to data node or a loop to cast the base class types to the desired type.

Unfortunately it also doesn't seem possible to have the VIM in the same project and just brought along to the support directory when building the PPL so it would need to come from a completely different project that depends on the built PPL and you could do something like a source distribution to "build" the VIM to the same folder the PPL is built to so the link paths get setup as expected from the VIM.

Community scope also tends to be problematic with PPLs. I don't see the need to community scope the VI for getting plugins of type since all the VIM provides overtop of it is the convenience of not casting the classes yourself.

---

This makes sense, and good point about the community scope, especially in this case since it's just a getter.

To your point about VIMs in the PPL build spec, that seems like someone just wrote some code that said "if any VIMs referenced anywhere in the PPL build, then fail" with disregard for how they are being used. I would expected just copying them to an output directory, as long as they are not included directly into the lvlib that's being built into the PPL, should be successful. Maybe a post build step VI is a good enough work around to copy the library with the VIMs where I need it.

[IlluminatedG]

It was real weird. When I included the VIM as an always-include but specified that it shouldn't be put in the PPL... the VI that was in the library was also put directly on disk and the PPL was empty. I was hoping it would be smart enough to build the PPL and link the thing not built into the PPL to the PPL but no dice and it just broke everything instead.

After you copy the VIM you're still going to need to relink the VIM to the namespace of the PPL (Library.lvlibp:GetPluginsOfType.vi instead of Library.lvlib:GetPluginsOfType.vi along with the expected path to find it) otherwise it will just keep forcing you to choose the lvlibp provided VI anyways because it's expecting the unbuilt version of the name with the original relative pathing to the source VI. Whenever I'm working with PPLs I always have a pretty structured built output layout that is the same relative path to all my source projects so things that depend on the PPLs can always find them in dependent projects. Once you go the PPL route you're more or less forced into many extra projects since things need to be linked against the PPL built versions.

[wiebe@CARYA]

---

@IlluminatedG wrote:

Ahh right. Yeah PRC won't work if you're returning an array, brain fart there.

---

Wouldn't a to more specific in a for loop work?

Of course you'd need a (parent) type, but there's way around that.

[IlluminatedG]

Can't do that in a non-vim VI and have it propagate out the type

[wiebe@CARYA]

---

@IlluminatedG wrote:

Can't do that in a non-vim VI and have it propagate out the type

---

Guess I'd have to see it...