“Preserve Run-Time Type” for Variants (in analogy to “Preserve Run-Time Class” for Objects)

[drjdpowell]

 I propose a “Preserve Run-Time Type” primitive for Variants that is analogous to “Preserve Run-Time Class” for Objects.  Below I illustrate, using a system of messages that I'm working on.  Two message types carry either Variants or Objects (LVObject).  In each case I must convert to a specific type (data type or child class) in order to use the messages data.  For this I can use "Variant to Data" or "To More Specific Class", but I need to do the conversion outside my "Read Message" subVIs (top two examples below).

However, with Objects I can make a cleaner implementation (third example) where I use "Preserve Run-Time Class" to do the same thing inside the "Read" subVI.  I would like to be able to do the same thing with my Variants but I cannot (but I've faked what it would look like in the forth example).

The object subVI that uses Preserve Run-Time Class looks like this:

A subVI using “Preserve Run-Time Type” would look similar, just with Variants in place of Objects.

In addition to cleaner code, “Preserve Run-Time Type” would allow additional logic to be built into the Variant to type conversion.  For example, I like to use numerics with units in my messages, as a safety device against message sender and receiver using different units, or confusing what the message represents.  However, one can always convert a numeric with units to a numeric without units by using "Variant to Data" with a non-unit type input.  This defeats some of the safety (eg, sender could send "output" in Watts, but receiver thinks it's in Volts).  I would like to make a message type that performs unit consistency checks inside the "Read" subVI, throwing an error on any mismatch; a “Preserve Run-Time Type" would allow this.

[drjdpowell]

> Isn't this exactly what Variant To Data does today? I can't get my head around to see the difference?

Steen,

This idea was motivated by a LAVA side conversation about the difference between "Preserve Run-Time Class" and "To More Specific Class".  It is not very intuitive, unfortunately, and it took me a while to understand it.   It's the difference between the type of a wire, and the type of the data on the wire, and can only come up with certain "generic" data types like classes and variants.  Very confusingly, preserving class on the wire at run-time inside a subVI allows preserving class of the wire in the caller of the subVI at edit-time. 

[tst]

I think part of the issue between you and AQ is that AQ is looking at the generic-I/O problem (which requires recompiled code) and you're only looking at a specific subset of that problem - the part which could be resolved with code which is fully compilable when it has a variant (because you just want LV to convert back from the variant for you). I agree that it would be very nice to have this and I am voting for the idea, but I could also see why NI wouldn't want to solve only that part of the problem with special code.

[drjdpowell]

tst, you forgot to vote.  Come on, I'm trying to get this idea into double digits 

I see your point, though it depends on the relative complexity of implementation.  This idea could be orders of magnitute simpler to make work.

[drjdpowell]

>Status changed to: Declined

At least I got tst's vote.  

[tst]

Mary/AQ, I would suggest getting the idea undeclined, as I don't think AQ's stated reason for declining it applies, as explained earlier. Maybe it should be declined (or at least not implemented), but it would need a different reason.

[AristosQueue (NI)]

I'm pretty sure my reasoning for declining this idea does hold, even after reading the rest of the comments. But let me double check...

You are looking to write a subroutine that has a variant input and a variant output (an implicit call to To Variant primitive). You wire a non-variant to the input, which puts a coercion dot on to show that we are coercing to a new data type. On the far side, you get the variant output, and you want the output terminal to be the same type and to have the compiler automatically generate the implicit call of the Variant To Data primitive.

Within the subroutine, there are two things you could be doing with the variant:

a) Only operations that do not involve converting that variant into data or

b) Operations that do involve converting that variant into data.

If you are only doing operations that do not involve converting that variant into data then the only reason to pass the variant through the subroutine is because you are adding attributes to the variant. If you are adding attributes to the variant, then the output needs to remain a variant or you've just lost the attributes. If you are not adding attributes then there's no need to pass the variant out of the subroutine in the first place -- just wire your double to the subroutine and to the next subroutine down the line, forking the wire.

If you are doing operations that convert the variant to data, you're building the dynamic type testing and/or poly VI system somewhere. I would say you should move it up an architecture layer and make the code more efficient by never constructing the variant at all. But -- and here's where we finally get to your idea -- you don't want to do that. After all, you've already got the polymorphism at some deep layer and you want the higher levels to just handle the data generically. So it seems reasonable to ask for this primitive. But the new primitive would not cause the terminals to propagate the type. Notice that you do not get automatic downcasting today among Control Refnums of different types. Getting that downcasting requires us to teach LabVIEW to do the same type of terminal thralling (our internal term for automatic downcasting) from source to sink terminals that LV classes do. For variants, it requires us to teach the compiler to introduce the Variant To Data code at the output. But the work needed to add that kind of thrall analysis is the same as the work needed to make generic type propagation work, as it requires all functions that can change the type to be identified and have different behavior in the type propagation and code generation. And though I admit that modifying the code generator to add the Variant To Data is simpler for us that doing essentially a "save as and replace type type" needed to do the generic code generation, the work isn't that far apart, and if I have developers to spare to work on the primitive, I'd rather add them to the actual generics project, which subsumes the need for this. The result is not just more broadly applicable, it results in code that is far more efficient for you since it dodges the variant ever being constructed.

Thus I see this as a poor stop-gap for generics, and not a sufficient stop gap to be able to get new features any time sooner.

Make sense?

[drjdpowell]

Thanks for replying,

>I would say you should move it up an architecture layer and make the code more efficient by never constructing the variant at all.But -- and here's where we finally get to your idea -- you don't want to do that.

At the moment I can't do that.  I don't have the tools to to move it up a layer.  And I'm perhaps too focused on improving the tools I have: analyzing and tearing apart variants with off-pallet or OpenG tools.  Not high performance.  If there is a shiny new thing on the horizon to supplant this then I'm all for it, though I have difficulty visualizing quite what this thing will look like.  I hope it is successful and worth sacrificing incremental improvements in the variants we have now.

Is there any public info on the kind of generics system NI has tried?  Just for my interest.

-- James

"Thralling" is the term I was lacking, BTW.  Getting thralling for variants is exactly what I was thinking.  

[mawodorfer]

There were mentioned XNodes to do the task we are discussing here. Is there any further information how to do this? I never used XNodes and documentation is not easily found.

[tst]

XNodes are not an official feature in LV, so you won't find any proper documention. There is some reference material on LAVA, but you should be aware that because they are not official, they can change/crash/etc. Also, my understanding is that NI also decided not to develop them any further because of problems they have, so I would not recommend relying on them.