Why are Overrides Made this Way?

[LuminaryKnight]

Creating a child class.  Right clicked the class and selected "VI for Override."  Selected one of the Dynamic Dispatched VIs from the Parent.  What's bugging me is why is the Parent VI included into the new Override VI?  Am I using the VI for Override the wrong way?  I would have thought it just made a block diagram with all the proper controls and terminals and that's it.  But the Parent VI is there.  Why's that?  In the snippet... CHMBR is the parent VI.  I don't understand why that would be included into the Child Override.  What am I misunderstanding/doing wrong?

[crossrulz]

It is a default working setup to just have the child call the parent method.  I'd say a good number of child methods call the parent method anyways, so I see no harm in it being there by default.

You can dig through this document and see if there are any more specific reasons.

[LuminaryKnight]

Okay, so the misunderstanding is it's just a default thing.  No programming rules are being broken.  Just delete it and move on. Just seemed weird the very override VI it'll be overriding would be included.

[BertMcMahan]

IMO, I use Call Parent maybe 60% of the time I override a VI, so it's nice to be there by default. For interfaces it doesn't really make much sense since usually you just have template VI's for interfaces, but for a lot of stuff it makes sense.

For example, say you have some sort of object that can save its state to a config file- let's use the classic "car" analogy. Vehicle.lvclass:Save to Config.vi might save "Weight" and "Price" variables; the next level override, Car.lvclass, might add in "Make" and "Model", then the next level override "Sedan.lvclass" might add "Trim package" (I'm not a car guy, lol.)

It doesn't make as much sense at the very top level, but multi-level overrides will usually call their parents unless they fully replace (rather than augment) the parent's behavior.

[LuminaryKnight]

Hmm... okay so let me ask the following, cuz maybe this is why it didn't make sense to me, but base off what you just said...

The uniqueness of the VI Icon, which appears to have a "To more generic class" icon is actually meaning that that VI will in fact be the Parent Method and will not override with the child Method.  I was understanding this to basically mean the Parent Method was going to override with the Child Method which would cause a never ending reentrant issue.  But saying all this out loud, that makes a lot more sense now.  The Parent Method will not override with a child method and is described by the "to more generic class" icon.

[crossrulz]

---

@LuminaryKnight wrote:

The Parent Method will not override with a child method and is described by the "to more generic class" icon.

---

It is more like the "to more generic class" overlayed on top of the method's icon.

Just to make sure we are clear, the override is only done when the method is called by the main application.  If the object is of the child class, the child's method will be called.  The child method then has the ability to also call the parent method by using the "Call Parent Class Method".

[BertMcMahan]

Yes, there's a slight difference that's not immediately apparent. The icon you see that shows up on the Child class method when you create it is not the parent method. That icon is actually the function "Call Parent Method", which calls the parent of whatever method it's on right then. The icon just happens to copy the parent method's icon.

This is different from dragging and dropping the parent method VI itself onto the block diagram, even though they visually look similar- it's just the little icon in the bottom left that's different.

[IlluminatedG]

I updated the override tooling in my install to not include that though I do want to update it so that it leaves it if the must call parent is specified in the parent class.

I'm in the camp of rarely using call parent method because sometimes it matters if the parent stuff is done first, last, or in the middle so I like to be explicit about the ordering of parent vs child behavior and will have a static vi called at the parent layer that calls override VIs at specific places for child provided behavior.

[Kevin_Price]

Just to add another thought tidbit for the OP:  I find "Call Parent Method" to be symbiotic with the fact that parent data is private and children cannot access it directly. 

For example, "Call Parent" generally comes first in my create / init methods and last in my destroy / de-init methods.  

-Kevin P

[wiebe@CARYA]

---

@LuminaryKnight wrote:

Okay, so the misunderstanding is it's just a default thing.  No programming rules are being broken.  Just delete it and move on. Just seemed weird the very override VI it'll be overriding would be included.

---

Just to add to the discussion...

There are differently reasons to override a method:

1) implement child functionality (e.g. if the parent is abstract or an interface)

2) extend parent method behavior (call parent method works for that)

3) replace parent method behavior (see Overwrite or override - Stack Overflow)

Since 2 is a perfectly valid use case, and since it's less work to remove the call parent than it is to insert it, they choose to make that the default.

Whether the default makes sense depends very much on what you're doing. If you're extending classes a lot, it's great. If you're implementing an abstract class it doesn't.