LVOOP: finding out programmatically if child class overrides VI

[Intaris]

You mention it's a static analysis, so you mean it's an edit-time information only, right?  Not run-time stuff?

[bokorpet]

It occurs during configuration of our system. Formally speaking it is run-time but it's before the real load gets underway.

We have a real-time system with lots of threads. So our "static analysis" (and you're right, I wasn't precise on that) is an analysis of the object so that we can handle it more efficiently (for scheduling etc.).

What I could do is to statically analyse the classes (edit-time) but ours is an open system so we don't have all sources.

[Intaris]

The difference being that Scripting is limited in run-time as opposed to run-time.

I have done things in the past where I have introduced a hierarchy into my objects where a method returns not only the required result but also strings which are built up from parent to child like "Grandparent.Parent.Child" so that you can exactly see which stages are called and which are not.

Create a Dynamic Dispatch function called "ID" which calls the Parent method and appends the current object's string to it.  You then end up with Parent.Child.Grandchild as an output string.  If Grandchild inherits directly from Parent, then you'll get Parent.Grandchild.  Then call this ID method in whichever method you may or may not overwrite.  Pass this argument out along with any other you might require.  It must be in the same method call otherwise it won't work.

I'll try to get an example up and running.

[Intaris]

Hmm, no, it Doesn't seem to work as I thought.

[Intaris]

Here's how "I" would go about it (LV 2012 SP1).  I had previously done it this way before, but without coupling the callchain info to a different method.  My initial idea that calling DD VI X in a DD VI Y would, when calling Parent.X in would actually call Parent.X but it still calls X, so if we cascade the results as I had implied, we get Child.Child and not Parent.Child.

So if you need this kind of thing, I would suggest statically adding this information so that you can build a callchain if required (you could turn the action off by adding a boolean input...).

This requires no reflection and is fast, but it DOES add baggage to the existing method.  I'm not sure what to think of it to be honest.

In the example I have defined two DD VIs in Parent.  One of them is inherited by Child AND Grandchild and when we run it, it gives a callchain of Parent.Child.Grandchild.  The other method is not inherited by Child, but by Grandchild so running this method gives a Callchain of Parent.Grandchild.  It's the information you need, but I'm not sure if the baggage is acceptable.  It also places requirements that all ancestor implementations append their tag correctly.

[mikeporter]

I have been out of the loop for a couple days, but going back to an earlier post, it sounds like what you want is multiple inheritance. If the is the case, there is a company that distributes a free toolbox for doing exactly that.

I remember seeing an announcement around the June-July timeframe last year as I was preparing my OOP presentation for NI Week.

Mike...

[Intaris]

I find this idea interesting from an academic point of view.

Here's a different method which returns the information from any given method based on how the parent is set up.

It internalises the strings created so that they can be read out from the object itself.  By not placing them on the diagram of the overrides, users expanding the functionality of the code cannot prevent it from working properly, it will always return the correct values.  Disadvantage is that it requires the VI to be executed.

[Intaris]

Here's another version which can be done without having to actually having to run the VI, but I'm not sure if it'll work in compiled code.  The node is available at run-time but I don't know what kind of information it returns.

[bokorpet]

We're industry and we need it so it's not academic for us 🙂

Call chain + string-based solutions: interesting, but since we cannot instrument the children, it's not directly viable for us.

VI server: same here, we don't have the source of the children.

The solution I posted is a simplified version of yours: the abstract parent DD method prints if it's called (which implies that the method is not overriden). In this way, only the parent method needs to be changed. This works for us as our framework is programmed against abstract classes/methods, whose sources we have access to. We don't care who the children are. If the parent's methods are not abstract and may need to be called, then your call chain approach comes in handy. So thanks for your help! 😉

Mike, thanks for the toolbox reference. Our workarounds do the job for the moment, but it's good to know.

Peter

[Intaris]

---

@Bokor wrote:

If the parent's methods are not abstract and may need to be called, then your call chain approach comes in handy. 

---

Well there's no such thing as a true abstract method in LabVIEW.  If you have only the callchain code on the BD of your parent and have the requirement for all descendents that they must call the parent method, then it's all you need.

---

@Bokor wrote:

the abstract parent DD method prints if it's called (which implies that the method is not overriden).

---

The simplified version you describe sounds like you only need to know if the base class method is overridden by anyone in the child hierarchy.  My understanding of "parent" class is no the same as "base" class.  Any given method of a "parent" class can itself be an overridden form of another class method.  A "base" class method is not overriding anything.  That difference was not clear to me based on the original post.  I also couldn't open your code, my LV version is too old (2012 SP1) so I was completely unaware of your current methods.  Either way, as long as you have a working solution all is good.