Bundled Project Library

[SteveChandler]

The only nice thing about llb files vs lvlibs is that they contain all the files for the library. But there is no namespacing, access scope, and they can not contain two files with the same name. The latter rules out dynamic dispatch. Packed project libraries solve this but they can be a pain to use and the vis can not be inlined.

I propose a new "Bundled Project Library" which is a hybrid of llbs and lvlibs. They contain all the functionality of an lvlib but actually contain the vis. These can be regular libraries or classes. This would resolve a known issue with VIPM when building class hierarchies.

[David S.]

I think this brushes against a broader question: Why is LV structured as one-function-per-file? Why not allow mutliple methods in a single file like every text-based language? Someone much smarter than me posed this answer once: "When your language has diff but not merge, do you really want everything in one file? When you have no concept of libraries [at the time the language was created], what facilitates function reuse the most? And besides, wouldn't it be nice if source code control for all languages could check out one function at a time to minimize resolving conflicts?"

I still see the advantage of having the ability to distribute one file that represents an entire logical unit of code. It seems to me that the solution might be improving the usability of the lvlibp?

[SteveChandler]

At least make the llb able to store a directory structure so that my class hierarchy will fit.

But for a "Bundled Project Library" The vis should behave exactly as they do when stored in individual files when using a project so diff and merge will still work as expected. The BPL would be a kind of virtual filesystem with the features of LabVIEW libraries.

And "contain all the functionality of an llb" should read "contain all the functionality of an lvlib" above 

[StephenB]

ive wanted the same thing many many times and feel the same way

+1

[JB]

Would a Packed Project Library meet all your needs ?

[AristosQueue (NI)]

I am a major fan of this as an option. I want to be able to distribute my library in a single *uncompiled still with source diagrams* file. It would help with both sharing the file and it would significantly help load times (because operating systems do single large file load MUCH faster than many small files).  I want it as an option, though, because I still want to develop with all the files separate. Even with spectacular diff/merge tools, having finer grain control means fewer conflicts means fewer times when I have to use such tools.

[SteveChandler]

@JB A PPL meets my needs for some things. But there are issues associated with them. "Issues" may be the wrong term. "Implications" is probably better. As AQ points out they are compiled.

@AQ This would not just be an option it would be a separate thing. I would still want to develop code against source control using the standard lvlib with no changes to it. I envision clicking on the build specifications and selecting New/Bundled Project Library. They would be stored with a new file with an extension such as .lvlibb