Inheritance, namespacing, and my aching head

[Daklu]

So I have an ActiveObject library template I copy into projects when I want to use an active object for part of the application. This library contains a dozen or so classes with up to 3 levels of inheritance. Earlier today I discovered that if I add ActiveObject.lvlib to another library in my project, such as Model.lvlib, all the ActiveObject inheritance breaks and I have to go through and relink everything. This is especially irritating when I hit the sticky mouse bug and accidentally remove ActiveObject.lvlib from Model.lvlib. I have to manually relink everything again when I add it back.

I'm guessing this is because the classes aren't smart enough to know (or maybe simply can't know) that the parent's fully qualified name was changed when it was added to Model.lvlib. Would be nice if a mass compile would fix it, but that fails because of the broken VIs.

I like Labview a lot, but it sure doesn't make component-based development very easy.

[Later]

I did discover an easier work-around...

1. Add ActiveObject.lvlib to the project, not as part of another library.

2. Move all my classes from ActiveObject.lvlib to Model.lvlib.

3. Move ActiveObject.lvlib so it is part of Model.lvlib.

4. Move the previous classes back into ActiveObject.lvlib.

[Edit -- much later]

An easier work around is to set the parent class' scope to something else, then set it back to what it is supposed to be. This apparently causes LV to reanalyze the permissions and remove the error.

[PaulL]

A similar issue I have encountered recently is when I converted a hierarchy of folders containing classes into a library (.lvlib), since I used these in multiple projects. When I opened the other projects, the calls to the methods now in in the .lvlib broke (although the class hierarchy actually updated to point to the classes in the new .lvlib--it almost works). In this case I just manually linked the broken VI calls.

Note:

I could have avoided this by planning to use .lvlib files from the start.

The namespace really does change, so there is some sense in which this is expected behavior.

Nonetheless, it is another example where a relatively minor improvement could make code reuse more efficient.

[Daklu]

I could have avoided this by planning to use .lvlib files from the start.

Yeah, all my reusable code now automatically goes in libraries. I also often use libraries to partition non-reusable code within an application, such as Model.lvlib, View.lvlib, and Controller.lvlib.

Nonetheless, it is another example where a relatively minor improvement could make code reuse more efficient.

I agree there's a lot of room for improvement in this area. I don't think it would be a "relatively minor" effort. I've talked to AQ about it in the past and it sounded like decoupling the namespace and library would have a ripple effect deep into Labview's internals.

[PaulL]

I agree there's a lot of room for improvement in this area. I don't think it would be a "relatively minor" effort. I've talked to AQ about it in the past and it sounded like decoupling the namespace and library would have a ripple effect deep into Labview's internals.

OK, it could be a good amount of work. On the other hand, I'm not recommending decoupling the namespace and library. I actually kind of like coupling the two, since it means (I think) we can have identically named classes in different namespaces. What I would like is for LabVIEW to be smart enough to relink (or prompt the user to relink) methods after a conversion to a .lvlib (new namespace). This does require support across projects, but LabVIEW already recognizes the change and puts the .lvlib in the project and links the classes, so it's almost there. It just needs to relink the calls. It's not the highest item on my priority list (by far) but it seems like it's almost there, actually. (The last bit could be trickier, of course.)

Paul

[Daklu]

On the other hand, I'm not recommending decoupling the namespace and library.

I see now. I misunderstood your failure mode and thought the new namespacing was preventing the classes from being loaded.

I actually kind of like coupling the two, since it means (I think) we can have identically named classes in different namespaces.

Yeah, you can have identically (short) named classes in the same project as long as the fully qualified name is different.

I'm not wishing for taking namespaces away, I just wish namespaces and libraries weren't so tightly integrated. They serve different purposes. Libraries are a functional grouping of related code. Namespaces are a logical grouping of related code. Lots of times their needs overlap; sometimes they don't. One thing I'd like to be able to do add classes to a library and gain the ability to define scope without changing the class' namespace. (I find this especially annoying since LV doesn't support inner classes.) I'd also like to be able to create hierarchical namespaces for reuse code. Due to the cascading load nature of libraries it's not very practical to do that in Labview. And sometimes I even want a single namespace to span multiple libraries.

This does require support across projects, but LabVIEW already recognizes the change and puts the .lvlib in the project and links the classes, so it's almost there. It just needs to relink the calls.

SpeculationMode.Enter();

In your situation the library is loaded because the .lvproj, .lvlib, and .lvclass files track of their membership by path. When the project loads a VI that is part of a library, the library file is loaded too and becomes part of the project. VIs, on the other hand, store references to other VIs and classes using the fully qualified (namespaced) name. If a sub VI's fully qualified name has changed when the calling vi is not in memory, it's going to be fairly restricted in its ability to correctly figure out which sub vi it should be using. (Whatever heuristics NI comes up with to resolve it is bound to be wrong sometimes.) Come to think of it, I don't think your use case *can* be addressed without decoupling libraries and namespaces.

In my use case, it turns out the .lvclass file stores the link to the parent class as a binary string, so it probably also uses a fully qualified name. What I don't understand is that everything is already in memory so why aren't the parent links automatically updated to reflect the new namespace without using the workaround?

SpeculationMode.Exit();

[jgcode]

I am having fun with .lvlibs too

[Aristos Queue]

I'm guessing this is because the classes aren't smart enough to know (or maybe simply can't know) that the parent's fully qualified name was changed

This is by design.

As far as the child classes are concerned, if they inherited from "A.lvclass" and when they load into memory they find "X.lvlib:A.lvclass", well, that's not their parent. You're asking kindergarteners to go home with strangers who happen to share Mommy's name. Won't someone think of the children?! :-)

If you change the parent's name while the children are in memory, then they'll know about the name change and not load broken. In other words, parents should bring the kids with them to the Justice of the Peace when they get their names changed, so we avoid these socially awkward scenes in the grocery store with the child screaming, "You're not my mother!"

:-)

Come to think of it, I don't think your use case *can* be addressed without decoupling libraries and namespaces.

Bingo. Absolutely correct. Unfortunately, that trick is not on the roadmap at this time.

What I don't understand is that everything is already in memory so why aren't the parent links automatically updated to reflect the new namespace without using the workaround?

When you changed the parent's name, did you do File >> Save All on all the children? Or did you exit without saving the children?

[Daklu]

If you change the parent's name while the children are in memory, then they'll know about the name change and not load broken.

That's just it... in my use case the parent is in memory. Parent and child are members of the same library, but changing the namespace of the owning library by putting it in another library breaks the inheritance.

I posted a repro on NI's forums. Looks like CAR 236169 was filed against it. Should be showing up on your desk in a day or so.

Bingo. Absolutely correct. Unfortunately, that trick is not on the roadmap at this time.

Damn. I'll buy you a root beer if you can sneak it on there.

When you changed the parent's name, did you do File >> Save All on all the children? Or did you exit without saving the children?

I didn't exit at all. Save All doesn't fix the error; you have to do one of the two work arounds I posted or manually unset and set the inheritance of every child class.

[PaulL]

Bingo. Absolutely correct. Unfortunately, that trick is not on the roadmap at this time.

I understand the problem here, and agree it is quite challenging. On the other hand, breaking all callers when converting to a library (.lvlib) seems quite undesirable, too. I think it sure would be good to have a solution in mind when planning the future.... (Even if this is a simpler way to relink broken calls that would be good. That might be harder than resolving the actual namespace issue, though.)

[Aristos Queue]

Daklu is correct -- the behavior was actually a bug in LV 2009. This CAR is fixed in LV 2010.

[PaulL]

Is it possibly you can clarify which CAR exactly? CAR 233951 (which is the number I have from NI) is not listed in the fixes (but it could be a duplicate?). I did a search on 'lib' in the bug fix list and the closest relevant result was: 193210 XML parser error when unflattening a LabVIEW class owned by a library, which was certainly a bug I saw (thanks for fixing it!) but I don't think it's the same issue Daklu is describing exactly.

[Aristos Queue]

CAR 236169 is fixed in LV 2010.

[Aristos Queue]

CAR 236169 is fixed in LV 2010.

233951 is a duplicate. It is also fixed in LV2010.

[PaulL]

233951 is a duplicate. It is also fixed in LV2010.

Cool! Thanks!