Jump to content

LVClasses in LVLibs: how to organize things


Recommended Posts

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

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.]

Link to comment

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).

Link to comment

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...

Link to comment
  • 7 months later...

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

Link to comment

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!

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.