Malleable vs Polymorphic

[1984]

Hi,

I have set of VIs returning different types of data (eg: U8, DBL, String, Arrays etc) based on a dataset name (string). All the datasets are stored in an FGV as variant. For every datatype I have a different VI which gets the data from the FGV and then using the variant to data VI to output the right datatype. (eg: Read U8, Read DBL, Read String etc)

These VIs are bundled into a polymorphic VI where the polymorphic selector is the datatype itself. In other words the programmer must know the datatype during the programming, but that is not an issue at all.

I'd like to improve these VIs in a way that the dataset name input can be a string as well as an enum. I see two options:

1. make the dataset name input a variant and then Format Variant to String VI. The problem with this is this VI is pretty slow (about 5ms / conversion on my PC), so the performance of the data query drops a lot. Another problem is that the VI now accepts everything on its dataset name input, so its prone to errors

2. another option is to make this VI malleable accepting only strings and enums. When the input is a string there is almost no performance drop and if its an enum it still pretty good. A great benefit is that the code gets broken if the user connects anything to the input other than string or enum. The problem with this is that I can't bundle malleable VIs into a polymorphic so I loose the convenience of the polymorphism. Note! Unlike other malleable VIs, in this one the output datatype can't be determined by an input datatype. I only experimented with malleable VIs to being able to handle both strings and enums on the dataset name input without too much of a performance drop.

So I'm kinda stuck here and I'm wondering if there is a better way to do this. Basically I need to a polymorphic VI which accepts strings and enums on a certain input terminal and can return different datatypes without too much of a performance drop (compared to a simple string input).

Not sure if this is possible at all, maybe I have to drop the idea of using enums or I need to drop the convenience of the polymorphic VIs.

Is there any better idea? Thanks.

[raphschru]

Hi 1984,

Please define clearly what a "dataset" is and how it is related to the string/enum input and the datatype of the output.

Also, you did not explain the interest of having an enum versus a string.

I'm sure this could be solved by using a malleable VI only.

And so we can help better, please post some sample VIs.

Regards,

Raphaël.

[1984]

---

Please define clearly what a "dataset"... 

Forget about thedataset (I probably misused this term), lets just call it data. You can store anything in the FGV as its stored in a variant. Most typical data we store are numerics, strings, bools and their arrays, but it really can be anything.

---

...how it is related to the string/enum input and the datatype of the output.

Inside the FGV the data is stored in a map where the key is the data name and the value is a variant. Other then this there is no relationship between the name and the type. Because the data is stored as a variant there is only one writing VI which is the "write anything". It takes the data name and any type of a data and adds it to the FGV without caring about the type of the data. And practically there is only one "Read data" VI which returns the variant part of the map based on the data name and that variant can be casted to whatever type. To make the programmers' life easier though, I created VI which wraps the "Read data" VI and takes care of converting the variant to the most common types. To give an example the screenshot below shows the "Read boolean" VI, which takes the data name, reads the data from the FGV and converts it to boolean.

Now it takes only a string, but would be nice to take enums as well. 

As explained the wrappers can be set to malleable and then it takes strings and enums and nothing else which is great. I just lose the polymorphic ability which I liked a lot as I could change the poly selector based on the datatype I needed there were no need to manually place a different VI.

---

Also, you did not explain the interest of having an enum versus a string.

The interest here is that in some cases its better to use enums than strings, like in case structure so many times. A typedef'd enum is not susceptible to typos and if I change the typedef the change rolls out everywhere, no need to search for strings. Overall its for convenience.

---

I'm sure this could be solved by using a malleable VI only.

---

Could be, but I didnt find a way. If the datatype would be an input of this VI then sure, but it would be mega annoying if the programmer would need to connect a U8 constant to the input of the VI everytime he wants to get a U8, thats what the wrappers for.

(I already have a malleable VI called "Read.Anything.vim" for data we have no wrapper for (eg: any custom clusters). This VI requires the data type to be wired, which is good flexibility for custom datatypes.

This is the "Read.Anything.vim":

Sorry, can't post a source code.

[raphschru · Accepted solution]

Ah I see, I think it is not possible.

As you know, you can't add a malleable VI to the instance list of a polymorphic VI, so your "Variables.Read.Anything.vim" will have to be separated from your polymorphic VI. This is actually logical. If you wire e.g. a boolean, LabVIEW could not determine (at least easily) whether to use the boolean instance or the malleable instance... Also, since this is a different way of using the function (selecting a predefined type versus specifying a custom type as an input), I think having 2 separate VIs (one polymorphic and one malleable) would make sense.

Regards,

Raphaël.

[1984]

Thanks for the valuable comments. The malleable solution is better in development time debugabilty and performance and worse in the sense that I can't make it polymorphic. The first two seems an overwhelming so I'm ready to drop polymorphism.

Actually in this case the polymorphic VI was not really polymorphic because all the poly instances had the same inputs (error cluster and data name). The difference was coming from the output data type so the polymorphic VI had no chance to select the right poly instance anyways. The benefit in my case was only that little selector box what I could use to select the right wrapper VI. Is there a way to somehow wrap my malleable VIs into a "polymorphic" looking VI which has a selector so I can select the right instance?

[raphschru]

This comes back to the original question, and the answer for me is no.

To my knowledge, only a polymorphic VI can have an instance selector (unless you decide to develop an XNode, which I wouldn't advise because it often creates more problems than it solves).

[paul_cardinale]

Did you know that "Variant To Data" reacts to the data type that is wired to the "data" output, and that you don't need to wire anything to the "type" input?

[1984]

Nope, I didnt know that. Cool. It doesnt seem to work though when the output of the variant to data goes thru a tunnel.

[raphschru · Accepted solution]

Some other examples why I wouldn't trust datatype back-propagation:

[paul_cardinale]

The datatype back-propagation:

• Only happens at the time the wire is connected.
• It based only on the type of the terminal it's connected to.
  • That means it can't propagate through tunnels (or anything else).
• Can't figure out what the type should be when connected to a polymorphic terminal.