Super Polymorphic VI

[Luke_G]

In LabVIEW, we can create a polymorphic VI, but polymorphic VIs are made by creating multiple disparate VIs and logically tying them together. What I'm proposing is a single VI which can be used to perform many different functions, as is normal in many text languages.

Imagine a class with 10 different functions, and the ability to read/write from each. We'd have 20 similar VIs. I propose a single VI with a tabbed front panel. When you select a different tab, you'd see a different block diagram. Each could have a different connector pane. When saved, it would create a single file. On a palette, it would be a single function. We could use a polymorphic selector to choose which function to operate on. 

This would simplify distribution of classes and drivers.

[fefepeto_kb]

I try to rephrase some of the topics I think you touched on and want to improve the experience with:

• Interacting with class functions (methods) trough a single block diagram node in the caller
• Storing and distributing class libraries or even entire libraries as a single file
• Window management of all VIs contained in a single class (tabbing the front panel of multiple VIs)

If I get it correctly the emphasis is on the distribution part, that would allow sharing the LabVIEW solution as a single file. For this very part, the packed project libraries are already available and a quite good solution.

For the other parts of the idea, in general I'm against having multiple methods stored in a single file, and definitely against having multiple classes in a single file.

In text based languages usually a class is stored as a single file, because the functions are separated by leveraging the code specific syntaxes. But even in text based code it is a good practice to store no more then one class in a file. It has to do with the development workflow automations that facilitate quality control by automatically analyzing and testing the files, but also allows more developers to work on the same codebase without causing merge conflicts.

This would also make applying modern principles like SOLID for OOP designs and clean code very hard if not impossible.

On the window management topic, I think there are multiple ideas on how and why it shall be improved, and they usually have explanations in the comments why they haven't been implemented yet (they are usually hard to change and a hot topic even among existing users).

For writing to class data, a.k.a. properties in a single node on the caller, well, that possible with property nodes. Just create the accessors the correct way, and you can interact with multiple read and write operations in a single BD node.

[Petru_Tarabuta]

It would be useful to have a single file on disk that contains multiple VIs. In other words, it would be useful to break the one-to-one  mapping between VIs (i.e. functions, methods, routines) and files on disk.

I guess this file type exists already: the LLB file. However, I don't know whether the LLB file can be included inside an lvlib or lvclass (I have never tried this). It is extremely useful for VIs and CTLs to be members of lvlibs or lvclasses. If the LLB can't be owned by an lvlib or lvclass, then its usefulness is limited.

An alternative, potentially more useful implementation might be: Each lvclass and lvlib file could store all VIs and CTLs inside one file. Imagine a class named "A.lvclass" which contains 20 method VIs and 5 CTLs. This would be extremely useful. In a sense, this implementation would combine the best of lvclasses and lvlibs (providing a namespace for each VI, ability to set Access Scope of each VI) with the best of LLBs: one file on disk.  

[crossrulz]

Petru, you are actually asking to go the other way: A lvlib and/or lvclass being stored in a llb. I just tested this in 2024Q3 and it actually does do this. You can save a lvlib and lvclass in an llb.

[fefepeto_kb]

I propose we change this problem to three separate use cases.

1. Use-case: Development and code sharing in a single file

If we had classes or full libraries in a single file during development that would cause a nightmare for a team working on the code.

Image this scenario MyLib.lvlib:MyClass.lvclass:MethodA.vi and MyLib.lvlib:MyClass.lvclass:MethodB.vi are in the same file.

They have been pre-generated by a script.

Developer 1 works on the MethodA.vi, while developer 2 works on the MethodB.vi. As long as they don't have to modify anything on the class itself, or a common dependency they can work perfectly parallelly. (I know this is not a realistic use-case, but working on two separate classes in the same library is more common, and shares the same problems.)

If LabVIEW moved everything in a single file, then this theoretical team would need an added tool, that can analyze the content of the file and show which one have been changed. There would be wrappers for the diff and the merge tools, to achieve this.

If we go one step further, and say that this team also has an automated testing implemented, then they need extra tools, that provide command line output of which classes inside the single file have changed, because the units tests shall be executed selectively, then the integration tests are also selective, etc.

2. Use-case: Development in multiple files and un-editable deployment

This is practically the (in)famous PPL, packed project library, which has improved a lot in the recent years, at least in my opinion.

The lvlibp files can be distributed, even debugging can be turned on for them, but they cannot be edited, so sharing these files with others only allows them to use the produced code.

3. Use-case: A single developer works on a code as a single file

This is the only use-case I think there would be some value add. When working alone and not having to share the code, the developer could keep everything in a single file without any additional hassle. But, this would still cause an increased storage need on any source code control server, would be impractical for trying to trace back older revisions of some pieces of the code, etc.

All in all, I think the potential benefits are very small compared to the potential issues with such an approach.