LabVIEW
Why can't I create property definition folders on an interface?
So, one thing that might not be coming across super well- and apologies if you understand this Tim- but "property definition folders" are not the same thing as "properties".
All that a property definition folder does in LV is to allow you to access a method of a class via a Property Node instead of using the VI block. That's literally it. There is no functional difference (that I've ever seen anyway). It's what some call "syntactic sugar" that can make some block diagrams look a little cleaner. For example, setting and getting 8 different properties looks a little nicer with two property nodes rather than 16 individual VI's on one diagram.
So, to directly answer your question: https://forums.ni.com/t5/Community-Documents/LabVIEW-Interfaces-The-Decisions-Behind-the-Design/ta-p...
(See page 11. The short answer is that they ran out of time, but that they plan on doing it later. Here is that idea exchange entry: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-us-to-use-interfaces-for-class-methods-that-use...)
To sum up, you can still make dynamic accessors for your interface. They look just like any other method. You just can't (by default) create property node supports for them, but that doesn't change their function.
The only thing you may want is for interfaces to have private data, which they cannot do. I think C++ lets you do that in virtual functions (but I'm no expert) but other languages don't let you have data fields in pure interfaces (Google says Java and C# don't let you, but I'm not certain on that.)
@BertMcMahan wrote:
IIRC, if a class has a method defined with the same name as an interface, it will default to using the one defined by the class itself. If it has two interfaces with the same method, you get a broken wire and must explicitly cast the object to the correct interface before it will let you call that method.
Quoting myself since I can't edit... this is wrong. This doc explains: https://forums.ni.com/t5/Community-Documents/LabVIEW-Interfaces-The-Decisions-Behind-the-Design/ta-p...
If a child class implements a method, that's always what will be called. If the child doesn't implement a method, and only one interface implements it, then the default method of the interface is called. If multiple parent interfaces implement a method and the child doesn't, then the wire will break- you are required to create an implementation for the child to explicitly define the behavior. If the child has a parent class that implements the method (and the child doesn't), then the parent class method is called, even if it also inherits from interfaces that also implement the method.
(end sidetrack)
. In the LabVIEW world, you'd have to write a slew of VIs in the base class that return meaningless constants (zero or whatever) and then require that derived classes override the default implementations for everything. Why pretend to support "interfaces" if you're going to require that?
Can you elaborate what you mean here? You have to create the same 'slew of VIs' for an abstract base class as for an interface.
As already pointed out by @BertMcMahan you are free to declare your getters/setters in your interfaces already. Property definition folders for interfaces are not that important. It is syntactic sugar to save block diagram space.
So what is the actual problem here?
So if the program that uses the device needs to record the device's cal date or serial number or whatever, it would need to cast the interface to the specific type. Doesn't that defeat the whole point of the interface? I don't want my HAL's knowing anything about the specific instrument classes- for one, it would statically link my "thing using the HAL" to every specific class, which is something I can avoid with interfaces.
I do see your point though. In the case of multiple behaviors, I think I'd have a separate "instrument" interface that provides all of the generic stuff as well as the "behavior" based interfaces you're talking about.
The software module that needs the voltage (e.g. a PID control) is propably not in need for the last calibration date. This is something that a study configuration module would likely be interested in.
This speaks for seperating behavior in lean interfaces to reach highly coherent code. But I am glad you brought up the "instrument" interface. I think I will consider this approach in a more granular manner, like: IRecalibratable, IConfigurable for the future
@TimBlaisdell wrote:
Replying to BertMcMahan.
Yes, I know all that. And the ability to call property accessors via a property node is precisely the point.
Unless one can first create a property definition folder, one cannot create the getter and/or setter that's required to be able to call the accessor via a property node.
Your answer smacks of the kind of answer that I've gotten before: "why would you want to create data accessors on an interface? An interface cannot have a private data cluster."
That answer sounds to me like it's coming from someone who doesn't know anything about object-oriented programming.
Suppose we're defining the most high-level, abstract interface imaginable: "Object". Even with such an interface, there may be one or two properties the programmer might want to require in any derived classes. For example "Name". When writing the over-arching framework that works with "Objects", the programmer might want to be able to retrieve the "Name" to show on the screen or whatever. So you'd like to be able to create a property definition folder called "Name" in the "Object" and add a "Read Name.vi" so that the Name property can be used as a property, and also to tell future programmers that they have to properly define this property.
Yes, you could create a normal virtual folder called "Name" and create "Read Name.vi" in there, and it may even be that when a derived class creates a property definition folder and puts "Read Name.vi" in there, it satisfies the must-override requirement, but it will not be callable via a property node when treating the object as an interface, as you've correctly pointed out, and that's a problem.
(Emphasis mine)
I'm honestly not sure how you read my answer and thought that I didn't know about OOP or that I thought you didn't want accessors. Perhaps you got some forum names confused? My answer was full of reasons you would WANT accessors on an interface. I linked to you the Idea Exchange entry asking NI to add property node support. I linked you the document where the R&D team that implemented interfaces agreed that "yes, we would like to do this, but we don't have time before we ship."
Honestly your answer smacks of someone who doesn't understand what a property node is, and it's likely due to some very poorly chosen naming conventions. A property node is not the same thing as a property, and a property definition folder is not where you define properties.
Perhaps you think the only way to access properties is via a property node? You can just use regular VI's for that. Yes, it's often more visually appealing to use a property node rather than a standalone VI, but it's not a requirement to implement the functionality. A property node is a visual re-styling of another VI, nothing more. A property definition folder is the way you reskin those VI's, nothing more.
You have made a good argument that interfaces sometimes need accessors. You can do this, as you said just using a normal "Read Name.vi".
You have not yet convinced me why it's an enormous problem that you can't use a property node for this. Is it obnoxious? Sure. Would it be more visually appealing to be able to use a property node, rather than a standard VI? Sure. Is there any actual functionality missing? None that I can see.
Responding to your specific points underlined above- first of all, you don't define properties using property definition folders, you define them in the private data control of the class. You can have properties without property nodes, and you can have property nodes that don't access properties. (I recognize that the naming here is stupid... a "property definition folder" sounds like the place to define properties, but it's not.)
Second, you don't use property nodes to tell future programmers that they have to define this property or implement this VI. You do that by right clicking the interface, selecting "Item settings", picking the accessor, and checking the box for "Descendants must override":
For interfaces, this box is checked by default, but you may uncheck it if you wish.
@TimBlaisdell wrote:
It's true that when defining an interface in LabVIEW, you have to create VIs for all the methods and properties, but the VIs only define the interface -- they are not callable. An interface is essentially a purely virtual class. There's no "default implementation" for anything -- an interface is that way by definition. Unlike a virtual class, which may have default implementation for some things. And more importantly, with a virtual class the programmer does not KNOW whether the VI for some method or property is merely a purely virtual definition, or a default implementation (without looking).
This is incorrect. The VI's defined in the interface are always the default implementation, and may be called by child classes. If the designer of the interface doesn't check the "Descendants must override" box, and a descendant doesn't override it, then the default implementation of the interface is called instead. Perhaps "virtual class" would be a better name for the construct we're currently discussing. Again, the reasoning behind this is well documented in the "decisions behind the design" paper I linked above.
@TimBlaisdell wrote:
An interface is essentially a contract the programmer makes with future developers (including his own future self), saying "this is the minimum that a class must do to work in this system."
Mostly true- see the checkbox above. If you click that box, then future devs know they MUST override that function.
I understand your terminology of private data vs. properties- thanks for the explanation. I think the big issue is simply that property nodes are a nice-to-have feature, which can be implemented the same way with normal VI's that simply look different. Since it's a purely cosmetic feature, it's not high on the list of things for them to fix. (Not that they've actually implemented many idea exchange entries in the last few years :()
@TimBlaisdell wrote:
NI representatives who have for some time been telling me that the reason you can't create a property on an interface is that an interface has no private data cluster. So "why would you want to create a property on an interface?"
Yet you can easily create a propery VI without any data access ... I agree with you, it should be possible and as an answer to that representative i'd like to answer "because i think ahead"
In C# it's just a definition, much like expected.
