lvlib question

[jzoller]

Something I've never quite understood... maybe someone can enlighten me.

Why does a VI need to know which lvlib it belongs to?

Joe Z.

[crossrulz]

VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs.

So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.

[Shaun Hayward]

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

[jzoller]

VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs.

So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.

That's a good description of how the system behaves, but not quite the understanding I'm looking for. Let me expand a bit

Imagine a VI of Water.vi contained in Bottled.lvlib. Further, imagine that, unlike the current system, the VI knows nothing about the lvlib. The lvlib is more of a pathing "hint".

The fully qualified name of the VI could be constructued depending on how the VI is loaded: from the lvlib, you get Bottled.lvlib:Water.vi. Loaded independently, you just get Water.vi. Further, the VI could also belong to River.lvlib, or other libraries. Changing the name of the lvlib wouldn't affect the VI, and different libraries could span common components. Namespace collisions would, of course, need to be resolved.

Obviously, this isn't the way LV works, but I would guess that it was considered. So, why the two-way relationship? What breaks without it?

Thanks,

Joe Z.

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

Good point.

I've not looked into the protection mechanism: good food for thought.

Thanks,

Joe Z.

Edit: need to think about this some more...

Edited July 31, 2009 by jzoller

[unicorn]

River and Bottle would be Projects. You can do the described feature with projects (and manually resolving your name conflicts).

[jzoller]

River and Bottle would be Projects. You can do the described feature with projects (and manually resolving your name conflicts).

Yep, that works... except for hierarchies of namespaces. Which application instance would your Bottled:River:Water run in?

Joe Z.

[Aristos Queue]

If the VI didn't know about the library:

• Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
• Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
• Classes, XControls and StateCharts -- all of which are libraries -- would not work.
• Licensing restrictions from NI would not work

That's it. ;-)

[jzoller]

If the VI didn't know about the library:

• Scope enforcement would not exist. A VI is broken unless its library is loaded... this is because LV assumes that if the library is missing, you're trying to access a VI that is marked as private by the library.
• Loading a VI needs to load its library so that it is *always* namespaced. Otherwise loading a large VI hierarchy would suddenly fail unless you loaded all the necessary libraries first because you would have a bunch of VIs with all the same file name colliding with each other.
• Classes, XControls and StateCharts -- all of which are libraries -- would not work.
• Licensing restrictions from NI would not work

That's it. ;-)

Ah, thanks Aristos, that explains it.

My personal use cases are a little different than NI's, so I wasn't seeing the reasoning.

Joe Z.

[Daklu]

Joe, you're mixing namespaces with library membership. Perfectly understandable as Labview defines namespaces by library membership, but the concepts serve different purposes and hopefully the day will come when users can define their own namespaces. (I've blown the namespace horn enough I'm sure AQ is quite tired of hearning it.)

The fully qualified name of the VI could be constructued depending on how the VI is loaded: from the lvlib, you get Bottled.lvlib:Water.vi. Loaded independently, you just get Water.vi.

Hmm... dynamic namespaces determined at run-time? Interesting concept, although I admit I don't see what problem this is attempting to solve.

Further, the VI could also belong to River.lvlib the {River} namespace, or other libraries namespaces. Changing the name of the lvlib namespace wouldn't affect the VI, and different libraries namespaces could span common components.

Allowing a vi to be exposed via multiple namespaces... I'm right there with you.

Namespace collisions would, of course, need to be resolved.

That's the whole point. With user-defined namespaces collisions are less likely to happen and when they do they are easier to resolve.