Unnecessary Polymorphic Types

[hooovahh]

I couldn't find a "Reuse Discussion" section so sorry if this could be in a better category.  

 

Lets say I have a reuse VI.  It does some stuff with data that is passed in but the type of the data doesn't matter so I make it a Variant.  Now this is sorta generic where I can use this with any data type, but there will be a "dirty dot" showing that a data type conversion took place whenever I use it with a data type other than a variant.  The more correct way to do this is to create a polymorphic VI, with a VI type for as many data types as I think will be used (string, boolean, VI Ref, path, numerics etc).  Then when this is used it will call the same Variant VI but with a "To Variant" primitive before calling the variant version.

 

My question is this.  Is all of this necessary?  If I create a VI that works with a Variant, do I really need to make types for all of them that simply have the explicit "To Data" conversion instead of just using the variant version that does the conversion it self.

 

One example I see of this is the "Data Changed?" VI from OpenG under the comparison pallet. This VI will work with any data type, and its default is a variant.  So why did OpenG go through the trouble of making a version that works with 40+ other data types?  In this example OpenG did not call the variant version but instead made one version for each data type, but I see the benefit of all other types just calling the Variant version.  This way if I make an update I just have to update the variant version and all others call that.  Otherwise any code update to one polymorphic types, means updating all other types.

[Yair]

So why did OpenG go through the trouble of making a version that works with 40+ other data types?

 

The main reasons are probably cleanliness, code safety and efficiency. A variant will cause a data copy, which is not a big deal if you're comparing a boolean, but could be an issue if it's an array with 10M elements. If you also make all your VIs work only with variants, then you will either start getting variants in the BD or the user will be forced to repeatedly convert back (and possibly make mistakes).

 

In the end, if you create a tool which will be reused many times, it takes considerably less effort to make it easy to use upfront than it does to make it simple to build. If you create an automated tool to help with the polyVI creation, then the effort becomes even more minimal.

 

The real thing we need here is for LV to be able to automatically adapt VIs to work based on input type. NI has known this for years, but so far hasn't managed to come up with a stable and reliable mechanism. Hopefully at some point they will and then we won't have to deal with this any more.

[hooovahh]

The main reasons are probably cleanliness, code safety and efficiency. A variant will cause a data copy, which is not a big deal if you're comparing a boolean, but could be an issue if it's an array with 10M elements. If you also make all your VIs work only with variants, then you will either start getting variants in the BD or the user will be forced to repeatedly convert back (and possibly make mistakes).

My intend was on the read to have a polymorphic VI for each type (variant being one of them) which performs the Variant to Data back to what is needed.  I only was curious about replacing all of the writes with one Variant VI.  I can't do the reverse because there's no way of changing a control at run time to the type needed.

 

 

In the end, if you create a tool which will be reused many times, it takes considerably less effort to make it easy to use upfront than it does to make it simple to build. If you create an automated tool to help with the polyVI creation, then the effort becomes even more minimal.

I did do this to make life a little easier.  I create the polymorphic instances programatically, but not the polymorphic VI itself.  I come to hate the polymorphic VI editor more and more with usability issues that make it slow to work with.

 

 

The real thing we need here is for LV to be able to automatically adapt VIs to work based on input type. NI has known this for years, but so far hasn't managed to come up with a stable and reliable mechanism. Hopefully at some point they will and then we won't have to deal with this any more.

Yeah I know, I can't wait to see the solution to this (sounds like not until 2015 or later).  

[Yair]

I did do this to make life a little easier.  I create the polymorphic instances programatically, but not the polymorphic VI itself.

 

I'm pretty sure that in recent versions the programmatic interface to poly VIs has improved considerably. The PolyVI class has an InstanceInfo property which I believe allows you to control the members of the poly VI.

[Norm Kirchner]

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Automated-creation-of-polymorphic-VIs/idi-p/2111968

 

Make sure to Kudo it

 

==================

Now to the idea of generics, I think one thing that would be help along these lines, would be to be specific of the "Killer App" that's not even possible without generics in LV.

 

One of these things that Brian Powell mentioned recently that made all the difference to me, is that we've got a limited number of things that we can focus on, and those can be the things that are not possible at all, or those things that we can do, but want easier.

 

Sure, life would be grand if we could do everything, but this is a much much harder problem to solve than you might imagine.

And when I say 'solve' I mean, do right, not make possible with a Multitude of bugs and limitations and gotchas (including corrupting your codebase)

 

So when it comes to having this feature, it would likely take a huge chunk away from making the impossible, possible.

But if you make a case where this is a huge benefit which is completely impossible, things start to get interesting.

 

So if you've got one of those, or even several, Make Them Known.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/C-like-Class-templates-for-Labview-classes/idi-p/1714078

 

Wish I had a better answer, but as an aside, if this is something not going into a product and you'll just use to make your life developing other code possible.....you might want to ping me offline

[Ton Plomp]

I did do this to make life a little easier.  I create the polymorphic instances programatically, but not the polymorphic VI itself.  I come to hate the polymorphic VI editor more and more with usability issues that make it slow to work with.

 

Polymorphic VI editor!

 

Ton