Let polymorphic VI adapt to sink

[SteenSchmidt]

When configuring a polymorphic VI you can enable "Allow Polymorphic VI to adapt to data type". This applies to input only:

I suggest to let this apply to output also. If there are any issues with enabling/disabling both together, it could be split into two selections: "Adapt to source" and "Adapt to sink" (or similar wording).

Cheers,

Steen

[smercurio_fc]

What happens if the VIs have multiple outputs, potentially conflicting? For example, one has a DBL and string, and another has an I32 and string and cluster. Since outputs do not need to be connected by definition, what do you do if the output is not connected?

[SteenSchmidt]

Then we do exactly the same as when multiple instances fit a connected input - basically select the first one that fits the bill (with some twists regarding type coercion and that sort). It'll always be possible to manually select some other instance than "Automatic". Fit to input type should take precedence over fit to output type btw.

Unless I missunderstand or overlook something in your comment?

Cheers,

Steen

[AristosQueue (NI)]

Like other recently posted ideas, this suggests upstream type propagation. I'm still not entirely comfortable with that concept. I'm not sure how intuitive it is. I'm not sure how it plays with coercion dots vs polyVI switching. And if that polymorphing changes input terminals, what implications does that have for actually getting a shift register type loop to settle out? Will the type feedback system be guaranteed to settle?

I'll give this idea kudos. It's an interesting area of research. But I have my reservations.

[altenbach]

What do you sugggest if the indicator is polymorphic? For example an xy-graph takes complex 1D arrays, cluster arrays of complex arrays, arrays of xy-points, a cluster of x and y arrays, arrays of such clusters, etc.

[SteenSchmidt]

I suggest the same as in my previous post; the first instance that fits the bill is selected, i.e. the first instance that doesn't break the code and will be without coercion.

The basic problem (selecting the poly-instances) seems relatively easy to solve. It'd be interesting to draw some state diagrams over though, but I need to get some sleep now..

I acknowledge Stephen's point of possibly winding up in a tug'o'war between a connected poly output and poly input. It might be an impossibility I'm suggesting, or if not impossible, then something that'll sometimes end up in a counterintuitive state. It needs further investigation. But if it is possible, it'd be a great feature. It's not on the top of my wish-list for new stuff, more like something to implement the next time the instance-selection algorithm is refactored.

Cheers,

Steen

[mattjsimps]

But what if the outputs are connected to a polymorphic input? Which one changes?

Not sure this is feasible. 

[mih]

I like this idea. I also had a situation where the output was polymorphic and was surprised that the automatic selection was not supported for the outputs. If inputs can be automatically selected then outputs should be as well. Nothing in the documentation suggests that polymorphism only applies to the inputs and it doesn't. Only the ability to automatically select the correct vi is treated differently. In my mind, connecting two polymorphic vi's to each other can be handled easily, by finding the first input datatype that matches, the first output instance. If there is no match, then use the second output instance, etc. If no match is found then we get the broken wire. If multiple polymorphs are connected in series, then the order in which they are wired will probably determine which instances are used.