Property Nodes for Interfaces
If you've wanted a LabVIEW Interface to contain data, well here's something that kind of approximates that.
When NI was developing interfaces in LabVIEW, there was a lot of chatter in the LabVIEW Champion's group. NI asked for opinions and well they got plenty of them. There was some serious debate about whether interfaces should have data or not. There were some serious suggestions, particularly from Dmitry that we should treat them like some other languages treat traits and allow them to contain data. Ultimately that idea lost out and the interfaces that we have in LabVIEW do not contain data. An interface in LabVIEW is just a set of function definitions with no private data. The question is, what to do when you want an interface to contain data? I've found a kind of workaround.
I'm a big fan of using property nodes with classes. I know not everyone is. There were some issues with stability when they first came out and I feel like that is kind of no longer an issue. I like property nodes because it is a much more compact syntax. Rather than calling several accessors in a row, I can expand a property node down. It also makes refactoring a little easier. When you move fields and methods from parent to child and vice versa if you use property nodes, in many cases the property nodes should just update. If you use an unbundle to access the field, then it doesn't work. You always get a broken run arrow.
Unfortunately, you can't create property nodes for LabVIEW Interfaces, at least not in the same way you can for classes. I'm not the first one to notice this:
However, I did realize that even though NI didn't implement the right-click menu in the GUI, if you manually edit the XML of an Interface you can create property folders. Once created this way they show up in the IDE and you can wire interfaces into property nodes just like you can wire a class into a property node.
In this way, the interface appears to have data. I say this because it doesn't actually have data. It just has the property node method, which is typically just a basic accessor. The method in the interface is blank because the interface doesn't have its own private data so it has nowhere to store the data. But if you make that method dynamic dispatch and must override, then any class that inherits from that interface must provide an override.
An example might be if you had an "instrument" interface and every instrument had a VISA ref property. Each class that inherited/implemented that interface would have to override those accessors in the interface class and presumably store the VISA ref in their own private data.
I created an idea on the Idea Exchange for NI to implement property folders for interfaces. The underlying mechanism works, all they need to do is add it to the right-click menu in the project. If you'd like to see this feature added, be sure to kudo the idea.
