Downstream polymorphism example for Idea Exchange comment

[AristosQueue (NI)]

Because I cannot put attachments on comments in the Idea Exchange, I am posting the VIs here and linking to this post from there.

This is for this idea.

[AristosQueue (NI) · Accepted solution]

This is not a question. It does not need an answer.

[Intaris]

I only just had a look at this code recently having been reminded of my idea due to a recent discussion.

It does not accurately reflect what I was asking for on the Idea exchange.

I consider the "Completed" for my idea to be incorrect.

I'll try to give more detail on the idea exchange.

Shane.

[Intaris]

The idea can, however, be treated as complete as menus can be created with Property nodes for Classes.  A bit non-intuitive but it works.

Shane.

[AristosQueue (NI)]

Comments in the idea exchange forum suggest that "Complete" is the right label for this idea. 🙂

[Intaris]

 Bah, Race condition.

It's not really completed but the suggested abilities are sufficient to make my original request kind of unneccessary.

More like "deemed irrelevant" then "complete" but I suppose if I take off my pedantic hat I can live with that....

[Intaris]

I'm trying to actually implement this idea in LV 2012 SP1 and I'm getting an error which seems to specifically prevent me doing what I want to do.

"The property definition folder named "Events" overrides a property in a parent class, but the overriding property accessor VI in the child class has a different filename than the accessor VI in the parent class."

Well, yeah, that's what I want to do.  The code provided by AQ works without error, but trying to reproduce a similar behaviour in my own code produces this error.  I have also created static VIs which reside within the property folder, each with a different datatype and different name but with the same name property folder.

What am I doing wrong?

The property of interest in "Parent" and "Child" is "Events".  Both of these VIs return different datatypes for each class.  Both are static VIs (non-DD).

Oh, I think I see the big problem here.... The classes in AQs code are not inherited from each other (They are not parent and child).  This ability only seems to work between "unrelated" classes.  This is a major problem for me.  I don't want an "Override" functionality, I just want it to behave as it does in AQs example.

Looks like I have to go back to maintaining polymorphic VIs....... Bah humbug.

Shane.

[tst]

I didn't look at the entire discussion again, but I would say that if you really do want to override (i.e select the Events property and have it call VI A or VI B based on the class going into the node), then you should make it DD and have the same name.

If you don't want an actual override, just name it something different from Events in the child class. I have no idea if it is or isn't possible to have different properties with the same name in different parts of the hierarchy (although I'm fairly sure that VI server does), but it's probably better not to have the same name just to avoid confusion as to which property you're calling (unless it's DD and then you shouldn't have a problem).

[Intaris]

---

@tst wrote:

I didn't look at the entire discussion again

---

Yes well, your suggestions, while do-able, defeat the purpose of the proposed solution.

The idea is to have automatically-updating property nodes with the possibility of having different returned datatypes.  DD requires the same connector pane, so different data types is a no-no.  Changing the porperty folder name prevents the auto-updating aspect so this is a no-no.

The "feature" as it currently exists (no functionality within a single class hierarchy) makes it almost useless to me.

Shane.

[AristosQueue (NI)]

Arbitrary type polymorphism between parent and child is a bug, and LabVIEW correctly rules it out. The contract of the parent needs to be upheld by the child.

I wish LabVIEW had covariant or contravariant parameterization of methods. That may be what you're trying to do in your case, Intaris.

Covariant would allow for class Mammal to have a dynamic dispatch VI DoSomething.vi with an output of class Shape and for class Dog (inheriting from Mammal) to override DoSomething.vi with an output of class Square. Currently, only the dynamic dispatch output terminals support covariance.

Contravariance would allow for class Mammal to have a dynamic dispatch VI DoSomething.vi with an input of type Square and for class Dog to override with an input of type Shape.

Contravariance and covariance allow the child class to maintain the promises of the parent class -- inputs that are more general than the parent, outputs that are more specific than the parent. Arbitrary type polymorphism would break the parent class' behavior entirely. If you need that, you need to create a new method with a new name because the parent has already provided your functionality for the first method. Breaking that symetry is a "feature" called "shadowing" in other languages. Shadowing, in all of my research, leads to more bugs in software than it ever helps and has been repeatedly looked at and repeatedly rejected by LabVIEW R&D.

So, if you're aiming for contra or co variance, I'm right there with you, wishing we had the feature. If you're wanting arbitrary polymorphism, that is correctly a polyVI.