LVOOP 'Call Parent Method' use cases

[Worle]

I have yet to really find a use case for the call parent method functionality of LVOOP.

The only possibilities I can really think of are:

- you don't want your override VI to actually modify the behaviour of the parent VI as summarised here (https://forums.ni.com/t5/LabVIEW/Why-is-my-vi-for-override-always-call-the-parent-method/m-p/3619870...)

- You want your child class to only slightly modify the inputs of the parent method but otherwise leave the functionality the same.

- I thought that there was almost a use case for putting code in the parent method which you always want to run regardless of what child class overrides it. Every time I have looked at doing this though the inputs for this code are the not the same as the actual methods and because the parent methods terminals have to match the override methods I end up with terminals that shouldn't be used by the override method. This isn't the end of the world but I get the sense it isn't how I should be doing this.

Are they the only use cases or have I missed something?

[LLindenbauer]

You might want to use this for initialisation. In the child constructor you call the parent constructor and then finish up the child-specific initialisation:

class Pet():
    def __init__(self):
        self.species = "Unknwon"
        self.fur = "shiny"
        
    def describe(self):
        return "I am a {} and my fur is {}.".format(self.species, self.fur)
    
class Cat(Pet):
    def __init__(self):
        super(self.__class__, self).__init__()
        self.species = "cat"
        
cat = Cat()
print(cat.describe()) # prints "I am a cat and my fur is shiny."

For example, you could implement an abstract device driver and add the communication interface in a child (I am not implying that it is a good idea to do so).

[wiebe@CARYA]

---

@Worle wrote:

- you don't want your override VI to actually modify the behaviour of the parent VI as summarised here (https://forums.ni.com/t5/LabVIEW/Why-is-my-vi-for-override-always-call-the-parent-method/m-p/3619870...)

---

If you don't want to over the parent's behavior, don't create the method!

It's silly to create a method that only calls the parent method.

Creating a VI with the call parent is not just the best guess, it's the only guess the 'create from override' can do though. Useful for your 2nd scenario, easy to delete (QD, ctrl+R) if not.

---

@Worle wrote:

- You want your child class to only slightly modify the inputs of the parent method but otherwise leave the functionality the same.

---

Yes, this is the one.

A child can be used to:

+ Implement behavior (override methods)

+ Extend behavior (add methods)

+ Change behavior (override methods and optionally call parent method)

This is very useful. I doubt I could do anything without this.

---

@Worle wrote:

- I thought that there was almost a use case for putting code in the parent method which you always want to run regardless of what child class overrides it. Every time I have looked at doing this though the inputs for this code are the not the same as the actual methods and because the parent methods terminals have to match the override methods I end up with terminals that shouldn't be used by the override method. This isn't the end of the world but I get the sense it isn't how I should be doing this.

---

Use protected static SubVIs in the parent instead...

If you don't make parent subVIs static, and start using them in children, and then start overriding them in (some) children, you'll create your own hell.

Note that you can, and sometimes have to, call the parent method without using call parent. When a child contains (an array of) parent(s), using call parent on them is a mistake. This will result in endless recursion. Call the exact method you're in, don't use call parent.