Follow-up questions from "G Interfaces in LV 2020" webcast (May 1, 2020)

[AristosQueue (NI)]

---

@Darren wrote:

---

@Jarrod_S. wrote:

Is a house key a tool?

---

No, in the shipping example, House Key inherits from LabVIEW Object. I don't think we need to make the edit to the project that Stephen made during the presentation.

---

Darren is right. In the heat of the moment, it seemed wrong. It's like looking at a word and suddenly thinking, "that can't be how that is spelled, can it?" But the example is correct! Phew.

[GregSands]

Really enjoyed watching the presentation, and looking forward to working out how to use interfaces.  One question on the class coercion issue shown when combining a Flathead and a Nailer - might it be possible to  right-click the Build Array node and select which class/interface, out of all possibilities in common, was output?  Same would apply to a Select Node, and perhaps to a Case statement output.  This seems roughly analogous to the Output Configuration property of some numeric nodes.

[pawhan11]

Are there plans to expose native LV interfaces so we can iterate over class (i am thinking like ienumerable and ienumerator in c#)

and many others that are used in LV primitives?

[AristosQueue (NI)]

---

@GregSands wrote:

One question on the class coercion issue shown when combining a Flathead and a Nailer - might it be possible to  right-click the Build Array node and select which class/interface, out of all possibilities in common, was output? 

---

Sure, we could (it's software... we can do anything). But there are multiple problems with this suggestion:

1. Build Array isn't the only place this is needed. Output tunnels of any multi-frame structure (case, event, disable) would need this option... the Select node would need this option... Min & Max node would need this option... any node that takes two object inputs and outputs an object output would need this option. And would need graphics updated to show when that option was in effect.

2. Use of the option would introduce another way a VI could break when you edit the class/interface hierarchy, which would be another unique error message. Instead of getting either a "not found" message on an object constant or a broken wire for incompatible types at the To More Generic node -- both of which you can easily see on a diagram and can quickly diagnose -- every individual node/terminal would have just another note in the Error List window with explanation text that this node had been configured to choose a parent that was no longer valid. There's not a lot of space on a terminal for us to graphically highlight this error, certainly not as much space as on a constant cube or a wire.

3. When the objects are inside clusters, you might have two different elements of the cluster each elevating in different hierarchies, which would necessitate a menu option per element. That would be a messy UI, I'm pretty sure.

[AristosQueue (NI)]

---

@pawhan11 wrote:

Are there plans to expose native LV interfaces so we can iterate over class (i am thinking like ienumerable and ienumerator in c#)

and many others that are used in LV primitives?

---

My team has had a finished spec document for how loop enumeration of a class would work since 2008, but it never gets prioritized over all our other projects. I keep lobbying for it. Specifically, it covers how a class (and, by implication, an interface) could:

• define how it connects to the ? terminal of case structures
• define how it connects to the stop terminal of loops
• define autoindexing on tunnels on loops
• define implicit coercion dots to any type

I've also doodled around with defining custom border nodes for the In Place Element structure, but that's more ambitious.

As far as the other LV primitives, no there are no plans to create -- for example -- a Numeric.lvclass interface for the math operations. I have some strong hesitation about going anywhere near operator overloading in G -- I touched on those concerns indirectly in the original LVOOP decisions document discussing overloading in general, and I've fleshed out those concerns in other posts over the years.

Having said that, specific APIs may very well benefit from that kind of interface support without creating the havoc of general overloading. If you have specific APIs to propose, then put them up on the LV Idea Exchange, and lets talk.

[AristosQueue (NI)]

During the presentation, Mike Le asked: "Is there robust scripting support for interfaces? For example, could you programmatically get the list of methods that make up a given interface class?"

My team follows a rule that ALL the dialogs that manipulate classes and interfaces are written exclusively in G using publicly available functions. To the best of my knowledge, that rule is unbroken. Since it is all in public G, that means that the functions to do anything we do in the UI must be available to anyone else writing G code. If there is a gap in our scripting coverage, I do not know of it. Because we have to be able to do things like list all the members of a class in the "Item Settings" page of the Interface Properties dialog, therefore I know the method to get all the members does exist.

Class refnums do have some private methods, but either those are used exclusively inside AppBuilder and are AppBuilder specific or we have created a public VI somewhere that wraps the functionality in a healthier API.

The list of all the new methods/properties on class refnums is in the Upgrade Notes.

In short, if I can write it, you can write it.

[AristosQueue (NI)]

For those of you interested in an example of using interfaces to create a Hardware Abstraction Layer (HAL) with some test-and-measurement-centric hardware, here's a customer developed example that appeared this weekend:

https://boringengineer.com/2020/05/03/labview-g-interfaces-solving-a-decade-old-problem/

I expect there will be many variations on this theme.

[AristosQueue (NI)]

---

@jlokanis wrote:

Quick question on Option A:

If ReallyForParent inherits from ReallyForActor, does that not then imply that ReallyForParent should extend ReallyForActor and therefore accept Stop and LastAck?

Maybe I am misunderstanding how Interface Inheritance works here.

---

a) You cannot wire a parent type to a child type terminal. That's a broken wire. So you could not directly wire ReallyForActor to the terminal ReallyForParent.

b) Last Ack and Stop are siblings of ReallyForParent. Definitely cannot wire siblings together.

Inheritance tree in Option A looks like this:

ReallyForActor

      |

      +--------------------+-----------------+

      |                    |                 |

ReallyForParent            Last Ack          Stop

[ohiofudu]

Thanks for sharing Mr Q "G" Rocks.

[jsiegel]

Slide 30 of the presentation shows a menu item to create a new Interface for Actor:

I don't have that option.  Is there something I need to do to enable it?  I do already have an actor in my project.

Note that the slide also shows a menu item for creating a new XNode, which I suspect is not supposed to be accessible to me.  Maybe it's the same for the Interface for Actor item?