Polymorphic + Malleable VIs

[GregSands]

My suggestion is that a Polymorphic VI should be able to contain Malleable VIs - as of LV 2018 this is not possible, and I don't think I've seen it suggested before.

The particular use case I have in mind is for a VIM which computes the average angle of an array of such angles, but changes a constant depending on whether angles are in degrees or radians.  The desired option is a polymorphic selector for Degrees/Radians which would then select the appropriate VIM.  The only available option currently is to add an Enum to the VIM. (A VIM is used to cope with representation and number of array dimensions).

[wiebe@CARYA]

---

@GregSands wrote:

The only available option currently is to add an Enum to the VIM.

---

Or an xnode, an express VI, variant inputs, or OO. All not ideal (except OO), but options non the less.

[GregSands]

---

@GregSandsOr an xnode, an express VI, variant inputs, or OO. All not ideal (except OO), but options non the less.

---

Yes, the VIM had been an XNode, just trying to convert as many as possible to VIMs, which are much easier to manage, and don't slow down the IDE.

[wiebe@CARYA]

Although I think there are some other alternatives, I wouldn't mind if polymorphic VI's could contain .vim's. +1

OT: Not to mention .vim's containing polymorphic VI's. (That works, until an executable is made. Then all instances need to be included, although everything should be compiled...)

[AristosQueue (NI)]

This idea was explicitly considered during development and rejected. In the LabVIEW 20xx platform, refactoring the code to make poly VIs and malleable VIs mesh is extremely non-trivial -- one uses a static list of connector pane patterns to select, the other uses a dynamic instantiation system.

LV R&D identified two use cases for blending malleable VIs with poly VIs:

1. Creating specialized algorithms for specific data types but having the malleable VI as a fallback for most data types.

2. (the use case cited by this idea) Using the poly VI not as a poly VI based on types but instead using it for its selection ring aspect.

We solved use case #1 in LabVIEW 2018 with the introduction of the Type Specialization Structure (the malleable VI simply subsumes all the alternatives that the poly VI would have provided). Use case #2 has no solution other than refactoring the code. We decided that although that is a nice-to-have editor feature, we did not deem it worth the expense of the code refactor. That remains true today.

LabVIEW NXG has eliminated the concept of poly VIs and handles the ability to create a substitutable set of VIs in a different manner, one that the malleable VIs will be compatible with, so when LabVIEW NXG eventually gets malleable VIs (likely a couple years away still), this problem will not exist.

For these reasons, the idea is rejected.

[Darren]

Declined for reasons listed in post by AristosQueue above.