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

[bsvare]

I assume there's overhead on the CPM that makes sense in the long run to remove to save some uS per call.  Wouldn't it be more efficient to build into compiler that checks for "blank" VIs and convert the call into a NOP? Then, if/when the parent call changes, the code doesn't have to be checked to re-add the CPM node for all child classes. I mean, it's a very specific call tree and LabVIEW doesn't support calling Grandparent's Method, so it's only 1 vi that has to be checked to implement the compiler optimization.   Also, on your added "Must NOT CPM" method, wouldn't that conflict with the transfer all must overrides to child classes option? I assume behavior would be very similar to the "Must CPM" option. However, I would think if you are extending a class with functionality, it make sense to CPM.

[Brainstorms]

But why bother CPM'ing to a method that by definition of the API is and will always be a "no-op" method?  Seems somewhat pedantic, doesn't it?  It's not like "there's a chance that the parent might have code in the future"; it's been decided that it won't.  Ever.  In the general case, the override includes the CPM, and in the general case, it's up to you to keep it or remove it.

LabVIEW does support calling grandparent methods.  Simply put a grandparent method VI and wire the grandchild to it.  That calls the grandparent class method on the grandchild class instance.  You may be referring to the situation of calling a grandparent method on a grandchild object when there is a parent override also defined on the grandparent method.  However, this is still supported by LabVIEW, although not in a simple manner.

To accomplish this, one only needs to upcast the grandchild object wire to the grandparent class ("manually"), skipping the parent class ("automatic" upcast) that the override mechanism provides.  Then call the grandparent method.  This will have the grandchild object run the grandparent method even though a parent override intervenes.  (A wrapper method would make this "clean" and appear as a single VI call on the BD.)

[AristosQueue (NI)]

> LabVIEW does support calling grandparent methods.

No. It does not. What you just described and what bsvare described are not the same thing AT ALL. 🙂

What bsvare talked about is calling of the grandparent implementation skipping the parent implementation of the current method.

What you talked about is calling a whole different method, which would call into the child's implementation if it had one and work its way back up the tree.

[AristosQueue (NI)]

> To accomplish this, one only needs to upcast the grandchild object wire to the grandparent class ("manually"),

> skipping the parent class ("automatic" upcast) that the override mechanism provides.

> This will have the grandchild object run the grandparent method even though a parent

> override intervenes.  (A wrapper method would make this "clean" and appear as a single VI call on the BD.)

If that works, all of LabVIEW is broken. There is simply no way that works... many MANY tests in the auto test suite would be failing.

Upcasting a child class to a parent or grandparent wire does not change the method that will be invoked when it reaches a dynamic dispatch node. If it did, not a single class framework would work.

If you can provide code that demonstrates this, I am very interested, as that means I have an extremely high priority showstopper CAR that needs to be fixed ASAP.

[AristosQueue (NI)]

bsvare wrote:

Wouldn't it be more efficient to build into compiler that checks for "blank" VIs and convert the call into a NOP?

No, not really.

a) That check would still have to be made at run time. The child VIs are not forced to recompile when the parent class implementation changes -- a deliberate design decision to make independent revision of parent classes possible in plug-in systems.

b) No parent implementation is ever truly empty if it has outputs. The constant values assigned for those outputs, whether they are propagating some other value (i.e. error in and error out)... that all matters.

[AristosQueue (NI)]

mthimm1 wrote:

but no adult programmer would do this.

You clearly haven't seen me code when I'm exhausted. But then, my brain is probably reduced to a child level at that time, so I guess your observation holds. 🙂

[Brainstorms]

Well, that reveals a bug in MY code... 

It changes the called method's icon to the grandparent, but not the run-time behavior.  I stand corrected!  (Now to correct my code...)

[AristosQueue (NI)]

It changes the icon to the GP icon to reflect that it is now capable of dispatching to far more places. When it was the child's icon, it could only dispatch to the child or its descendants. As the GP, more family joins the fun!! 🙂

And, for the record, as sorry as I am to hear you have a bug in your code, I am breathing a sigh of relief. A bug like that would represent a major hole in my work.

[Brainstorms]

Yes, what I described changes the dispatching point, but what I should have realized is that it does not change the run-time behavior.  So if there is an override at the parent level, the run-time behavior will still select that as the closest-available implementation of the method for the class on the wire, the grandchild class.

My bug is not major; I had created a method in a (mostly) abstract parent actor class that provides common + default behavior.  If there is an override actor class defined (and I have only one so far), then its behavior extends & calls that parent method.  I was anticipating additional subclassing, which would, at each level, necessitate calling (what would amount to) the "grandparent" class for the common behavior.  That won't work as envisioned.    Not a big deal to fix, thankfully, and I hadn't trapped it yet because I had not yet created intervening classes that would trigger it.

The moral of the story is that one needs to be careful to remember that although upcasting will change the edit-time method icon, it will NOT change the override selection behavior when the code runs -- even though it may appear to be doing so.  The IDE can & will make an icon change based on what it knows at edit time (re: class hierarchy and defined methods/overrides), but if you manually upcast around that, it still doesn't change the fact that overrides are not selected at edit time, but at run-time -- which is the whole point & value in OOP.  Oops!