Get Data Name is a misnomer?

[asbo]

The point was raised that the Get Data Name VI in the OpenG Labview Data package doesn't quite live up to its name in an intuitive sense. In the same VI scope, it correctly gets the name of the data on the wire, but in a subVI the terminal changes the name of the wire, and so the output changes:

FWIW, the Flatten to XML node behaves the same way, but I think Get Data Name would more aptly be Get Terminal Name. Anyone think it's worth changing?

[crelf]

I don't think it's a misnomer - something before it was called changed the name of the data, then when it's called it returns the name correctly, so I think it's working as expected.

[asbo]

Then in that case, I would argue that what we're talking about here is not a data name, it's a wire name. A data name would be a label I'd expect to follow a given instance of data through its lifetime, with some nuances if it's value is modified. Going through a terminal into a subVI, though, isn't a modification.

[crelf]

Then in that case, I would argue that what we're talking about here is not a data name, it's a wire name. A data name would be a label I'd expect to follow a given instance of data through its lifetime, with some nuances if it's value is modified. Going through a terminal into a subVI, though, isn't a modification.

Well, wire's don't have "names" per se, but they do have labels...

Anyway, LabVIEW is a dataflow language, I think what you're after is the name of the raferenced data up the chain, which you should pass some other way.

[Daklu]

Then in that case, I would argue that what we're talking about here is not a data name, it's a wire name. A data name would be a label I'd expect to follow a given instance of data through its lifetime, with some nuances if it's value is modified. Going through a terminal into a subVI, though, isn't a modification.

I also tend to think of a piece of data existing independent of any given vi, so from that perspective I agree with you. However, I'm not sure that's necessarily the correct way to think about it.

As I understand it, each vi is allocated its own data space in memory. No other vi has permission to edit that data space. When a parent vi passes data into a sub vi, the sub vi's data space gets its own, independent, copy of the data.** The "name" of that data space is defined by the wire name, which in turn is defined by the terminal name. In other words, there is no independent "name" attribute for individual pieces of data (unless you explicitly add one,) only names of data spaces.

So while part of me thinks it would be more clear to call it Get Terminal Name, doing so also kind of obscures the underlying nature of dataflow.

(**Yes, we know compiler optimizations often are able to eliminate unnecessary data copies so strictly speaking it might not be true. But it's still useful to think about it that way.)

Edited March 9, 2012 by Daklu

[crelf]

So while part of me thinks it would be more clear to call it Get Terminal Name, doing so also kind of obscures the underlying nature of dataflow.

My thoughts exactly.

[Wire Warrior]

I think "Get Terminal Name" is a better name for the VI. It more correctly references what the VI does. My first thought on reading the VI name in this thread was that data doesn't have a name it has an address in memory. I guess the context the word 'data' refers is the confusing point. Terminal referring to its use within the LabVIEW environment drives the context to the correct space.

[asbo]

Anyway, LabVIEW is a dataflow language, I think what you're after is the name of the raferenced data up the chain, which you should pass some other way.

This hits on a good point. I thought about it more and in the thread I referenced I don't necessarily agree with needing to know the name of the event at all, so perhaps it's a moot issue because there's not a good use case for it. I agree that if the name is significant, the data should be structured such that the name attribute is discrete (cluster {string name, userevent ref}).

I also tend to think of a piece of data existing independent of any given vi, so from that perspective I agree with you. However, I'm not sure that's necessarily the correct way to think about it.

As I understand it, each vi is allocated its own data space in memory. No other vi has permission to edit that data space. When a parent vi passes data into a sub vi, the sub vi's data space gets its own, independent, copy of the data.** The "name" of that data space is defined by the wire name, which in turn is defined by the terminal name. In other words, there is no independent "name" attribute for individual pieces of data (unless you explicitly add one,) only names of data spaces.

So while part of me thinks it would be more clear to call it Get Terminal Name, doing so also kind of obscures the underlying nature of dataflow.

I agree with everything you've said, except I guess I disagree with the implication that the data has a name - which, if I'm reading this right, you would agree it does not. The name belongs to some single instantiated item, which is why I suggested either terminal name or wire name, but the data has a source and destination(s) and has potentially many instances. You could argue each of these instances have different names, but I still have issue with saying that the name belongs to the data.

I don't think I found the right words there to justify my position, but I think this will boil down to semantics at best and philosophy at worst.

I think "Get Terminal Name" is a better name for the VI. It more correctly references what the VI does. My first thought on reading the VI name in this thread was that data doesn't have a name it has an address in memory. I guess the context the word 'data' refers is the confusing point. Terminal referring to its use within the LabVIEW environment drives the context to the correct space.

2-2! Tied up!

[crelf]

I thought about it more and in the thread I referenced I don't necessarily agree with needing to know the name of the event at all, so perhaps it's a moot issue because there's not a good use case for it. I agree that if the name is significant, the data should be structured such that the name attribute is discrete (cluster {string name, userevent ref}).

That said, I don't mind if it's used internally to a VI - I can see a use case for that. Maybe what we need here is an update to the OpenG function's context help to let people know about the limitations.

PS: What happens when you cast data? Is the name of the data now the name of the toCast element, or does it make it through?

[Daklu]

2-2! Tied up!

Yeah, but Chris has a Hollywood smile and killer sig, so we get extra points for that. (Besides, you'd need more than a simple majority to justify breaking an existing api.)

Maybe what we need here is an update to the OpenG function's context help to let people know about the limitations.

I think that would be an appropriate solution.

[Ton Plomp]

Get terminal name is definitely wrong, just because it's correct in one case, it's not valid in all cases. (Chris mentioned typecast).

Get data name is correct to me. The code is specifically used for variants, so if you want to use is, you should package the data as a variant, in that moment the name is preserved (however you can change it using OpenG code).

Ton

[Aristos Queue]

Speaking as someone who often sees LV from the underside, I think of this as "Get Data Type Name". The name returned is the name that was part of the data type at the time we compiled this VI for the wire that created the variant. That's the nearest named terminal upstream, but the name is preserved as you pass through tunnels, so it isn't necessarily the name of the nearest terminal.

Having said that, "Get Data Type Name" is a terrible name for the VI for most people because it is not the same as "Get Name of Data Type", which would be "Int32" or "Double". :-) So "Get Terminal Name" is the nearest to technically accurate that doesn't mislead people further. When you start dealing with LV classes, the problem gets even ickier because the name of the data type is always "LabVIEW class instance", the name of the class of the data type is "your class.lvclass", and the data type (terminal) name is "whatever you typed on the nearest upstream non-tunnel terminal".

Summary: I can see why "Get Terminal Name" would be a better name for this VI, and I cannot propose a better one.

[crelf]

...but Chris has a Hollywood smile...

I grew up in a country untouched by modern dentistry

PS: Read Molvania: A Land Untouched By Modern Dentistry - it's hillarious!

[Rolf Kalbermatter]

As I understand it, each vi is allocated its own data space in memory. No other vi has permission to edit that data space. When a parent vi passes data into a sub vi, the sub vi's data space gets its own, independent, copy of the data.

LabVIEW is a little smarter than this. Data to be passed into a subVI is only copied if it branches of to some other function too that can not operate independently on that data, such as any inplace operation or another subVI. Otherwise LabVIEW schedules the function that does not potentially (it doesn't know if a subVI would modify the data, but assumes so for safety) modify the data, to execute before the subVI or any data modifying operation in order to avoid the data copy entirely.

The data space of a VI has little to do with possible parameters wired into and out of the subVI but a lot with state information for the VI and things like shift registers.