Do.vi parent method - shouldn't it be called?

[mthimm1]

I have a probably silly question:

When I create a new message automatically, a do.vi that overrides the parent method is created. Why doesn't it call its parent method? I am aware of the fact, that it doesn't do anything. But if this changes in future versions then in many applications the parent method will not be called.

Since I had problems using the automatic message generation tool I didn't use the automatic message creation. Due to this in every message do.vi calls its parent method.

[Oli_Wachno]

Hi,

I don't really understand, why you would like to call the parent method (which has no functionality).

You can of course modify the framework to implement some standard behaviour to Message.lvclass:Do.vi... a better way would be to create a class MyMessage.lvclass as a child of Message.lvclass implementing the default behaviour and have your messages inheriting from MyMessage. Thus you could leave the original framework untouched. And if you need the Call Parent in your automatic message maker, modify the template.

[AristosQueue (NI) · Accepted solution]

This is a contract that the AF has made -- that the base implementation is and will forever remain a no-op. This is something that has to be done by convention in many programming languages. This is why I have plans to add a "Must NOT Call Parent" option in the future to LabVIEW so that this contract can be formally declared by the programmer, removing exactly this ambiguity.

The current convention is, in general, if the method is marked as "must override", then you never call the parent unless it is also marked as "must call parent". How are you as a programmer supposed to learn that magical convention? Osmosis from the environment, I suppose. 🙂 But that's why I'd like to augment the language to answer that question.

[stbe]

when I have these kind of abstract functions, I raise an error ("You must override this method ...") when the VI is called

hm, do you mean an "abstract class" option or only for single methods within a class?

[mthimm1]

As I mentioned a probably silly question.

I do not _want_ to call the parent method. When you override a dynamic dispatch vi, the call parent method vi is inserted automatically. I find this normal, usually the behaviour of the previous implementation is extended by the child implementation.

I was asking why the automatically created message does not call do.vi of the parent method. Since most people use it, I should be able to  safely remove all call parent method vis from my do.vi vis.

I had already in mind that the parent method does nothing and I have no need to change this (hopefully I won't have need to change this ever). But my question was about future LV Versions and future AF Versions. They cannot change the behaviour since applications build with previous LabVIEW versions probably (very likely) do not call the parent method.

I do not use the automatic message maker, because I am faster without, I need to be more flexible in naming and defining message methods (according to my employers coding scheme) and in my LabVIEW installation it crashed randomly. Automatic code generation still something suspicious for me although I know people who benefit a lot from it.

[AristosQueue (NI)]

Per method. My survey of code from users suggests that the fine grain option is useful to have... even on non-abstract classes, there's always this open question of whether a given method needs to call the parent implementation or not.

[AristosQueue (NI)]

The standard "new override" adds the CPM because a) that makes the node start off with the same functionality as its parent and b) it is easier to delete template code than to add code if you need it and c) my original survey suggested that most overrides wanted to call the parent version, but I've suspected in recent years that isn't true, but (a) and (b) are both sufficient reasons on their own.

In the case of the Do method, the scripting tools know the contract of the AF, so they don't bother scripting a call that would just hurt performance.

[AristosQueue (NI)]

mthimm1 wrote:

Automatic code generation still something suspicious for me although I know people who benefit a lot from it.

So, you avoid wiring arrays to the Add primitive then? 🙂

Just kidding with you... you're not the first user I've heard say that, but it amuses me because automatic code generation happens so frequently, nothing gets done without it. To me, there's zero difference between "automatic code generation" and "a compiler." 🙂

[mthimm1]

Thanks a lot. I would appreciate to have a "must not call parent" option even for my own classes and I would appreciate, if then overrides would not insert the call parent node automatically. There is also a "must override" option and I would find this fair.

During compile such stuff is very likely optimized, so the impact on performance should be non existent. But it would be more aesthetic in my opinion.

Now I know at least, that it is not only safe but recommended to remove the call parent vi's from my do.vi.

[mthimm1]

The difference between that kind of automatic code generation and compiling is, that the compiled code is not supposed to be read by humans. You can read it, but it should be optimized for machines. It might be faster to repeat 5 times identical code but no adult programmer would do this.