Why can't I have a Polymorphic Dynamic Dispatch VI?

[Shaun Hayward]

If polymorphic VIs are "compile time polymorphism" and LVOOP Dynamic Dispatch VIs are "runtime polymorphic"... is there any reason (besides the fact that LabVIEW doesnt let me) combine the two?

As an illustrative example: I may have a database that must be initialized with either a connection string, or a UDL file path. If no classes were involved, the ideal way I would implement this is with a auto-selecting polymorphic VI. However, if I then want to be able to create optimized database libraries for particular database types, the logical way (to me at least) would be to create a Database.lvclass:initilizeString.vi and a SQLServer.lvclass:initializeString.vi, with the SQLserver.lvclass, overiding the generic initialize method. However, this approach destroys the polymorphic capability as my Polymorphic VI cannot handle dynamic dispatch VIs.

I guess my work around is to create a bunch of static VIs calling dynamic dispatch equivalents (a la DVR classes) but, as with DVR classes this seems a little bit hacky and a bunch more work than it should be.

Am I alone in thinking that (a) this would be something useful, and (b) is there a fundamental reason this shouldn't happen?

Shaun

PS. I was thinking about adding this to the idea exchange, but wanted to get the opinions of you guys on here first!

[Aristos Queue]

If polymorphic VIs are "compile time polymorphism" and LVOOP Dynamic Dispatch VIs are "runtime polymorphic"... is there any reason (besides the fact that LabVIEW doesnt let me) combine the two?

No, no other reason. It is something that LV R&D would have to implement, and it has never percolated to the top of the priority list.

I guess my work around is to create a bunch of static VIs calling dynamic dispatch equivalents (a la DVR classes) but, as with DVR classes this seems a little bit hacky and a bunch more work than it should be.

Yep. I agree that it's more work, but it's not a hack, insofar as we said, "Well, there's a reasonably obvious way to make this work. Given that, let's deprioritize the ease-of-use feature for having poly VIs contain dynamic dispatch VIs directly."

It still isn't on the roadmap for any of the near term releases. It is not on the Idea Exchange... you should go post it there and see if it drums up enough support to get attention.

[Yair]

I can't check at the moment, but do DD VIs not require that you have the same conpane for all the VIs (aside from the DD terminal, obviously)?

The whole point of poly VIs is that you can have different conpanes ("different" meaning same pattern with different I/O) and that what you wire determines (at edit time) which VI to use based on the difference between the conpanes. It seems to me that this would prevent DD VIs from being polymorphic (unless you used the exact same conpane, which limits this use case considerably).

Or am I missing something?

[crelf]

The whole point of poly VIs is that you can have different conpanes ("different" meaning same pattern with different I/O) and that what you wire determines (at edit time) which VI to use based on the difference between the conpanes. It seems to me that this would prevent DD VIs from being polymorphic (unless you used the exact same conpane, which limits this use case considerably).

Well that may have been the motivation for their development. but I don't think it's the whole point. Or, at least, the idea polymorphism in LabVIEW has made other techniques possible (or easier). For example, sometimes I like to have a poly parent that has children that are selectable based on the required functionality, not actual polymorphism (the inputs and outputs might be the same between the children). It gives the developer a smaller palette and the ability to really quickly swap between functions. It takes some forethought to group items intelligently, but I think it's a vaild use of the polymorphic paradigm.

[Aristos Queue]

Or am I missing something?

Poly VI A.vi contains instances B.vi and C.vi, each of which has a unique conpane. There's no reason a descendant class couldn't have an override for B.vi or C.vi or both. It wouldn't allow the child VI to add D.vi to the poly VI, but it would let the child customize the behavior of the conpanes as given.

[Yair]

Ah, so working with Shaun's original example, the poly VI would have DB:Init with String.vi and DB:Init with UDL File.vi (one of which would be selected at edit time, based on the inputs or manually) and each child class could override these. Now I get it.

[Shaun Hayward]

Ah, so working with Shaun's original example, the poly VI would have DB:Init with String.vi and DB:Init with UDL File.vi (one of which would be selected at edit time, based on the inputs or manually) and each child class could override these. Now I get it.

Sorry for not getting back to this until now... but in short, that was exactly what I was trying to do before finding out that it wasn't allowed.

I'll head over and add it to the idea exchange and see what happens... thats for affirming I wasn't completely crazy!

[Daklu]

For example, sometimes I like to have a poly parent that has children that are selectable based on the required functionality, not actual polymorphism (the inputs and outputs might be the same between the children).

Great idea! I have a bunch of "Error (and/or/not) Bool" utility VIs that would be perfect for this.

[Aristos Queue]

For example, sometimes I like to have a poly parent that has children that are selectable based on the required functionality, not actual polymorphism (the inputs and outputs might be the same between the children).

Crelf & Daklu: You do realize that this is possible in LV today, right? And has been around since at least LV 6.0? The DAQ VIs are rife with this usage.

Create a PolyVI... On the configuration page for that PolyVI, there's a checkbox for "Show Selector by Default". This makes the poly VI instance selection ring appear under the node when you drop it. Then when users wire up to the node, they can select from the ring which bit of functionality they'd like to use. It's almost like having an action engine where the action is required to be a constant directly wired to the node. When I first learned about polyVIs, I filed a bug report that the poly VI wasn't broken even if two member VIs had the same inputs. Someone pointed this checkbox out to me, and I thought, ah, ok, now it makes sense. I let the bug report close as "not a bug." I did suggest that if there are two VIs added to the poly VI whose inputs are identical that the poly VI should be broken unless this checkbox is checked. That was rejected because it might break existing poly VIs that users had. Makes sense, but you should still be encouraged to use this checkbox for that case.

Maybe you knew all that, but it sounded like from your post (Daklu's in particular) that you didn't.

[crelf]

Crelf & Daklu: You do realize that this is possible in LV today, right? And has been around since at least LV 6.0? The DAQ VIs are rife with this usage.

Um, yeah - that's why I posted about it Actually, it was the DAQmx VIs that first gave me the idea to make my own...

When I first learned about polyVIs, I filed a bug report that the poly VI wasn't broken even if two member VIs had the same inputs. Someone pointed this checkbox out to me, and I thought, ah, ok, now it makes sense. I let the bug report close as "not a bug." I did suggest that if there are two VIs added to the poly VI whose inputs are identical that the poly VI should be broken unless this checkbox is checked.

That was exaclty my thought when I first started playing with polys - shouldn't it forbid me to have two VIs with the same conpanes as poly children? I'm glad that it does allow me to do it (especially, as you pointed out, with the checkbox checked), but I think it would be a good idea to have a warning dialog if you do it - I can imagine all sorts of hair-pulling-out if you didn't mean to do it.

[Daklu]

Maybe you knew all that, but it sounded like from your post (Daklu's in particular) that you didn't.

I understood what he was saying, but before reading his post I hadn't realized it was possible. I had just assumed that poly VIs had to have different inputs. It never occurred to me that it wasn't a requirement.

I did suggest that if there are two VIs added to the poly VI whose inputs are identical that the poly VI should be broken unless this checkbox is checked. That was rejected because it might break existing poly VIs that users had. Makes sense, but you should still be encouraged to use this checkbox for that case.

There's always the option to draw the instance icon instead of the poly icon. If the icons are good enough to distinguish between the different instances then there's no problem, even if they have the same type inputs.

[Aristos Queue]

There's always the option to draw the instance icon instead of the poly icon. If the icons are good enough to distinguish between the different instances then there's no problem, even if they have the same type inputs.

Kind of... without the selector being visible, there's no way to select the alternate functionality, so it might as well not exist. And without the selector, I think it is reasonable for any user of the the poly VI node to assume that all the functionality is available just by wiring inputs. Drawing the instance doesn't really help with those usability issues.

[crelf]

Kind of... without the selector being visible, there's no way to select the alternate functionality, so it might as well not exist.

You can right-click on a poly VI and "Select Type".

And without the selector, I think it is reasonable for any user of the the poly VI node to assume that all the functionality is available just by wiring inputs.

I agree that having the selector there is much more intuative for this use case.

[jgcode]

I understood what he was saying, but before reading his post I hadn't realized it was possible. I had just assumed that poly VIs had to have different inputs. It never occurred to me that it wasn't a requirement.

I love to create APIs like this.

And used to do it alot when I used MFVI/Action Engines for encapsulation.

Now I would rather use LVOOP so I don't do as much.

Anyways I wanted to add:-

Don't forget that ":" in your Menu Name lets you create submenus which is really handy for creating a menu hierarchy for the developer to navigate.

[Daklu]

Kind of... without the selector being visible, there's no way to select the alternate functionality, so it might as well not exist. And without the selector, I think it is reasonable for any user of the the poly VI node to assume that all the functionality is available just by wiring inputs. Drawing the instance doesn't really help with those usability issues.

I agree that it's not very discoverable, especially in cases where we have, say, 8 instances and 2 of them have matching inputs. The boolean/error vis I referred to earlier all have the same conpane, so there's no way to select a different one other than the context menu (or the selector.) If the developer is familiar with the api of that particular poly vi it shouldn't present a problem. Still, this technique is probably best suited for private internal code rather than public consumption.

[Mads]

Sorry for not getting back to this until now... but in short, that was exactly what I was trying to do before finding out that it wasn't allowed.

I'll head over and add it to the idea exchange and see what happens... thats for affirming I wasn't completely crazy!

 

Did you ever post such an idea? I could not find it...andwould like to have this feature too.

Right now I have a file type class where I wanted different versions of the file format to be children. These would have dynamic dispatch functions that would be part of polymorphic VIs for read/write operations (handling different data types).  

[Yair]

Did you ever post such an idea? I could not find it...andwould like to have this feature too.

 

Well, there's one now - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Use-Polymorphic-VI-inside-classes-as-dynamic-dispatch-to-emulate/idi-p/3210827