Rules of PolyMorphism ?

[CoastalMaineBird]

LV2013 SP1

Attached is a simplified LV2013 LLB which shows my difficulty.

Open the TEST POLYMORPH vi.  You don't need to run it.

This pic shows the trouble, too. 

The INPUT CHANNEL and OUTPUT CHANNEL are both STRICT TYPEDEF clusters.

There is a third type called CHANNEL , which is also a STRICT TYPEDEF cluster

The CONVERT TO CHANNEL is a PolyMorphic VI, with two consitutent parts, CONVERT INPUT CHANNEL, and CONVERT OUTPUT CHANNEL.

The Polymorph channel is set to AUTOMATICALLY ADAPT, so that it should correctly select the instance according to the type that you wire to the input terminal.

It doesn't.

What's fooling it, is the fact that the three clusters all have the same data type.  They have different NAMES for the items, but the items themselves are in the same order.

They are all STRICT TYPEDEFS, stored separately.

LV KNOWS that they are different, because the conversion VIs show a coercion dot when wiring from one to another.

It KNOWS they are different, but it will NOT automaticallly pick the right one, because the first one it finds is "good enough".

I have tried reversing the order of the VIs in the PolyMorphic VI, and the problem moves - it picks the FIRST one that is "good enough".

What I'm expecting is for it to find the BEST match to choose which instance.  Obviously, I'm expecting too much.

Does anyone know of a reference which states this behavior for a fact? Or am I missing something?

Maybe this is a problem for OOP.  I haven't tried OOP since LV 8, when it was a slow, crash-prone clusterthing.

But, if the problem shows up here, woudn't it show up there, too?

[nathand]

This doesn't surprise me. I remember seeing a somewhat similar discussion about error clusters, and that if you create a cluster of a boolean, a numeric, and a string, LabVIEW will treat it like an error cluster (including changing the cluster border and wire color).

---

CoastalMaineBird wrote:

Maybe this is a problem for OOP.  I haven't tried OOP since LV 8, when it was a slow, crash-prone clusterthing.

But, if the problem shows up here, woudn't it show up there, too?

---

No, because this polymorphism is completely different than how OOP dynamic dispatch (which I'm assuming is what you're referring to) works.

Slightly off-topic suggestion: try OOP again. If you don't have any OOP background (from another language), you won't see the benefits in the first few classes you create, but after a few attempts it will click.

[Hooovahh]

Yeah I think nathand is right.  The adapt to type basically tries each option one at a time, until it finds it doesn't have a broken arrow and uses that.  There has to be more logic to it because a polymorphic VI for a double or a U32 will adapt to type properly and not just pick the first that the coersion works with.

I'd say this is a bug and NI can fix it, but it is very low priority, especially with the work around being to pick the type explicitly.

Don't fear OO in LabVIEW, it has came a very long way since 8.x.  I don't use it often, but I know it is stable, until you get to a few hundred classes at which point there might be some slow down, but even that might have been fixed.

[CoastalMaineBird]

There has to be more logic to it because a polymorphic VI for a double or a U32 will adapt to type properly and not just pick the first that the coersion works with.

So, why is that?  I ran a test and you're right, but I don't understand the rules.

I defined a TYPDEF as an I16, I defined another as an I32.

I made a VI to convert the TD I32 to a DBL, I made another VI to convert the TD I16 to a DBL, I made another to convert a SGL to a DBL.

I made a Poly VI to incorporate all three.

All selectors are set to AUTOMATIC.

The TD I32 selects the right one.

The TD I16 selects the right one.

The SGL selects the right one.

The non-TD I32 has a type coercion, but IT PICKS THE RIGHT ONE.

The non-TD I16 has a type coercion, but IT PICKS THE RIGHT ONE.

I tried it with the I16 version first in the Poly list, and with I32 first. It does the right thing either way.

So, why doesn't my original work?

Maybe a CONVERSION is one point AGAINST this VI being chosen, and a COERCION is one point against.

No - then it would have chosen the VI with NO coercion and NO conversion.

[CoastalMaineBird]

Don't fear OO in LabVIEW, it has came a very long way since 8.x.  

--- I don't fear it, It just doesn't do what I want it to do.  I'm an old hand at object Pascal, wrote dozens of programs with objects.

I looked at it for this, but it doesn't work.

I want to have a structure which is "generic", i.e. it could be any of 8 items.

It has a TAG (U64) to identify exactly what it is, a NAME field, an ACTIVE field, and 30-40 strings, which are details.

I treat it generically for UI purposes; there's a tree that displays them, and you can drag and drop them; copy and paste, make them ACTIVE or INACTIVE, change their NAME, all without paying a LOT of attention to exactly which flavor it is.

I want to CAST it to a specific type, which just renames the strings from generic names ("string 1") to Specific names ("module ID") depending on which flavor it actually is.  Then I can deal with it as a specific type.

All that works fine now, but I was thinking that I could use Polymorphism to do the conversions, and have fewer VIs to actually find and place. 

If I try to have an OBJECT as the generic root thing, and have a descendant object as the specific thing, then I have to have getters and setters to translate the names for me.  That's a performance hit that I don't want to take, and it doesn't simplify my work, anyway.

[CoastalMaineBird]

especially with the work around being to pick the type explicitly.

Well, that is exactly the point of my trying to use polymorphism; I wanted to place a single VI and have IT pick the instance, rather than what I'm doing now, which is to place the specific instance myself.

You can't get there from here.