LVClasses in LVLibs: how to organize things

[drjdpowell]

I have a largish set of reuse code for inter-process messaging that I've been using in all my new projects. But I realize that I haven't really thought about how to organize things in Libraries. Given the difficulty in reorganizing libraries once they are referenced by many different projects, I'd like to get a good organization decided now. Currently, I have one large library with many classes in it, but that leads to any project using any part of the library loading every single class in it (and lots of VIs), even if individual projects only use a small subset of the classes. Classes that aren't in the library only load if needed, which seem a better feature. This makes me wonder if I shouldn't keep Classes in Libraries at all, unless they are very closely connected such that they will always be used together.

What do other people do in organizing with Classes and Libraries?

-- James

[PaulL]

We went through pretty much the same process of discovery.

Short answer: Yes, we put classes that work together to perform some specific tasks (e.g., configuration) in a library (.lvlib). We also put classes (or other files) in a library when a group of these form part of a template but in each instance we need a unique namespace. (The library provides a namespace and we don't have to rename all the individual contents. We can also copy the entire library on disk at once.) Finally, sometimes we have a group of child classes that obviously go together (for examples, we have Commands.lvlib and States.lvlib that contain children of CommandThisComponent.lvclass and State.lvclass, respectively.) In all cases we need all elements of the library in the project anyway, and it is actually quite handy to have everything grouped under a library in the project. (I think this is an especially important practice, by the way.) When these situations do not apply (i.e., we have a class that we may call all on its own) we usually do not put classes in libraries since we do not see an obvious benefit. (Putting disparate classes in a library adds unneeded items to the dependencies, as you say. We could make a library for an individual class, but especially since a class is already a library there doesn't seem to be anything to gain by doing that.)

The other thing to keep in mind is that if you open a nested library it will open the parent library and any other libraries in the nest.

Paul

[soupy]

There really isn't a correct way to do this as long as you steer clear of the following 'gotchas!'

• if you have a class in a library, renaming the library will reset the class mutation history.
  
  • this is only a problem if you are flattening class data and saving it to a file or passing it over the network.
    
  • this isn't a reason to avoid packaging classes in libraries, just a warning not to change the library name
    

  [*]if the case that you are passing data between different top level applications, put the type definition for that data inside a library and not a class!

  • placing the typedef in a class will force the other application to open the entire class into memory or the exe build.
    
  • i once added 7MB to an exe by adding a single type definition!
    

  [*]if you are using labview 2010, upgrade to 2011. libraries and classes are way less stable in 2010.

This isn't an exhaustive list, so feel free to add to it.

[Aristos Queue]

Classes are libraries, so you already have namespace protection for the VIs therein. I only apply a library wrapper when the classes will always be loaded together. Classes that are just distributed together as part of a toolkit don't get packaged into a library. The only exception that I can imagine is if you're using licensing (available from NI for those in the NI Partner's Program) since licensing requires a library wrapper.

[drjdpowell]

Thanks everyone, I think I'm slowly getting a better feel for how to structure things. Mostly by keeping classes out of LVLibraries, but identifying small groups that need to be closely tied together. I actually have a small section of my messaging code that uses Command-Pattern messages; if I don't put them in a Library I could accidentally build an exe that wouldn't contain its own commands! I might retain a library for the core classes that will always be needed; though the boundary of such a core isn't very distinct, so perhaps not.

I also like Paul's idea of a set of classes as one template. I don't (yet) have any such groupings, but I'm toying with the idea of a Command-Pattern-style Actor Template (ripping off inspired by the Actor Framework) and that would involve a template of multiple classes.

Part of what motivated my question is that I am currently in the middle of trying to adapt my messaging system, up to this point working only within a single Application instance, to work via TCP between different App instances or over the network. Thus, I've had to consider the issue of different instances having limited subsets of the messaging package (particularly if one instance is on a memory-limited Real Time system). A whole new dimension to worry over...

Thanks again,

-- James

[PaulL]

Classes are libraries, so you already have namespace protection for the VIs therein.

Just to clarify what I meant: I have a template and in that template I may have a set of classes. I use those classes in the same way in different applications (say, AppA and AppB), but each instance must be unique (because I need to use both pieces in a still larger application, and they link to specific typedefs for A and B, for example, so they are not common code). I can rename each class with an A or B extension to provide unique namespaces, but if there is a group of classes it is simpler to package them together in a library and then rename just the library with an A or B extension to provide a unique namespace.

[i'm looking at my actual template and I only see one case where we actually do something like this with classes. More frequently we have libraries for typedefs and shared variables where the libraries have component IDs in the names. The templatized code also has libraries with classes for States and Commands (concrete implementations of abstract classes), since we want to load these into memory as a unit; they form collections.]

[drjdpowell]

Well, I can't say that was fun, but I've managed get my code in such a way that only required parts of it will load. I found that I had a few VIs here and there that existed to help use diverse classes together. I had placed these helper VIs inside one of the classes involved; because of this they served as linkers that caused all the classes to load when the first one did, even if that VI and those other classes were never used. Just dropping an instance of my parent class loaded 75% the entire toolkit! Tracking these Vis down and getting them out of the classes broke the cross links. I found a use for a few LVLib libraries to hold collections of these VIs and others that didn't need to be in their related classes (and didn't always need to be loaded with the class).

[mje]

Due to recent experiences, I've sworn off using classes in lvlibs. I appreciate what lvlibs bring to the table, and I would like to use them, but from a practical stand point, I don't want to wind up in that situation again.

I have a far bigger project that combines the use of lvlibs and lvclasses, which has also become neigh uneditable, and frankly, I'm afraid of January when that project pushes to the top of my priority list. Last time I tried removing the association with the lvlib, things didn't go so well...

[drjdpowell]

Seven months later and I’m working on getting my reuse messaging code in a VIPM package. And another issue occurs to me. I now have most of my classes outside of any lvlib library, which prevents unnecessary loading. However, that means I have rather generic class names like “ErrorMessage”, “Messenger”, and “Actor” with no further namespacing that I could easily imagine another package using. What do other people do about this potential conflict?

— James

[PaulL]

Well, I still think the best solution is, in fact, to use project libraries (.lvlib files) where appropriate. Yes, one does have to think about which classes to put in a library to avoid loading unneeded classes, etc., but I suggest that means the solution is to use libraries carefully, rather than not to use them. Namespacing is important!

[Aristos Queue]

Or name your classes differently. I use a combo in the actor framework... there's the "Actor Framework.lvlib" that wraps the generically named but always used together "Actor" and "Message" classes. But the "Batch Msg" class is off on its own, as that's a bit less generic. Chance of collision? Yes. Fact of life, I'm afraid, since LV's libraries aren't merge-able namespaces.

[drjdpowell]

I wish it were easier to change namespacing once code is used in multiple projects. Or if it were possible to define a “display name” and a separate unique identifier that one could leave unchanged. So my “Actor” class could secretly be “47D44584FGHT” or whatever. No collisions then.

[jgcode]

Seven months later and I’m working on getting my reuse messaging code in a VIPM package. And another issue occurs to me. I now have most of my classes outside of any lvlib library, which prevents unnecessary loading. However, that means I have rather generic class names like “ErrorMessage”, “Messenger”, and “Actor” with no further namespacing that I could easily imagine another package using. What do other people do about this potential conflict?

This is a concern I share as well

I append a __<insert company name> tag to the end of the Class/Library name for reuse code (packaged using VIPM also) - I am pretty confident that this avoids collisions from other companies

[Daklu]

I wish it were easier to change namespacing once code is used in multiple projects. Or if it were possible to define a “display name” and a separate unique identifier that one could leave unchanged. So my “Actor” class could secretly be “47D44584FGHT” or whatever. No collisions then.

Not quite the same thing, but see this and this.