LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
oskretc

Use Polymorphic VI inside classes as dynamic dispatch to emulate overloading of methods

Status: New

 

 

The idea of overloading methods is wide spread in other languages. Labview already supports this in a way with polymorphic vis.

 

The code snippet below has 2 classes, parent and child

 

methods are described in the image below. 

 

The underline idea is that parent can define 1 method (poly.vi) that can handle multiple inputs (polymorphic) but does not have to implement the functionality for all the input types (it just needs to know about them) and the child class can override poly.vi and the interface it want to implement.

 

overloading methods.png

 

 

Even though the code above is correct, Labview gives an error.

 

"Dynamic dispatch VIs cannot be members of polymorphic VIs."

 

I dont see why not, since dynamic distpacthing will still have an entry point for both classes (poly.vi) and choosing which polymorphic vi to use will be define at design time.

 

 

5 Comments
tst
Knight of NI Knight of NI
Knight of NI

 

> I dont see why not...

 

Short answer: no technical reason.

Longer answer: see here - https://lavag.org/topic/11649-why-cant-i-have-a-polymorphic-dynamic-dispatch-vi/


___________________
Try to take over the world!
Mads
Active Participant

>Longer answer:....


Or in other words: people should give this idea a kudos to get things going...Smiley Wink

 

Personally my first use case for this was when I wanted a class that handles different file formats (handled by different child classes) to also have polymorph sub-VIs to handle different data types within the files. There are ways around this of course, but to me it is a case where the most intuitive solution is not supported, for no apparent (valid) reason.

AristosQueue (NI)
NI Employee (retired)

There's an easy workaround, which is why this idea hasn't gotten more traction -- create a static VI wrapper around your dynamic dispatch VI, mark it as inlined, and add that to your poly VI. You now have something that is functionally identical to LV having built-in support for a dynamic dispatch VI in your polyVI. It's a pain to have the extra file, but it works, and the use case appears to be rare enough that it just never gets to be a priority, not in almost 10 years of LVOOP (10th anniversary is next NIWeek).

Mads
Active Participant

Easy work-around requirements (or perhaps we should call them "huh, that does not work/is not supported, why on earth not?"-situations) are OK every now and then, but LabVIEW has accumulated too many of them over the years. Smiley Frustrated

RobStone
Member

I have to agree with Mads.

 

Just today I'm "celebrating" my 5th Working-with-LabVIEW anniversary. And I don't remember a single (real) feature NI introduced in the last 5 years which was completely fleshed out (with exception of the upcoming Channel Wires, it seems).

 

The two main reasons for that "dilemma" are IMHO:

1. NI is afraid to break compatibility between LV-Versions

2. Less profit (in the short term)

 

Regarding GOOP: It doesn't matter if there is a workaround or not. The real issue is that GOOP should not have been released 10 years ago with a feature set smaller than other object oriented languages at that time.

 

Just my 2 cent.

Rob