LabVIEW
Why can't I create property definition folders on an interface?
@BertMcMahan wrote:
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 :()
There was a time when our feedback was considered valuable and you would see a bunch of new features with the flag that showed they came from the idea exchange with every new version. 😞
Replying to BertMcMahan
One last thought regarding "nice-to-have" features that "simply look different" and are "purely cosmetic."
Far more than for any other programming language I've encountered, appearance, aesthetics, and cosmetics are important in LabVIEW programming, particularly when you have a team of developers working on a project.
We had a guy here who insisted on using a different font size on his block diagrams than everyone else. He was an old-timer, so he could get away with that. When anyone else opened his code, it was almost unreadable.
Anything that can reduce the clutter on a block diagram is valuable. If I can access a bunch of properties with one property node, rather than 5 or 10 separate calls to property accessors, that's very good. That kind of thing is extremely valuable in LabVIEW -- like I said, far more than for any other language. In C# property accessors are rightly called "syntactic sugar". It's the difference between
obj.setValue(1);
and
obj.Value = 1;
What's the big deal, right?
In LabVIEW, it's the difference between
and
Of course the above example is so trivial, someone might say "what's the big deal?" to that too. But I'm sure you realize how complex a VI can get, and how important clarity and readability can be.
I do fully agree with that- I use them too, and wish we had them- but I've seen other LabVIEW programmers argue that property nodes are actually to be avoided since they're text-only, and are not localized as well as a simple graphical image. Their style is to remove all text as much as possible, even going as far as to never use text in their icons.
(I don't personally follow that philosophy, but it's interesting to think about at least!)
One potential workaround would be to make some templates to use for accessors that are smaller, and thus take up less space on the block diagram. I call it a "workaround" since it's a change you have to make for a silly reason, and it doesn't really get you what you want, but it might help 😕
@TimBlaisdell wrote:
Replying to BertMcMahan
@BertMcMahan wrote:
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.Hmm... I was today years old (as the kids say) when I learned that you can uncheck "Descendants must override" for a method in an interface. LabVIEW will then treat the interface code as a parent-class implementation, and let you call it.
What is wrong in having functional code that doesn't need to get overriden?
@TimBlaisdell wrote:Hmm... I was today years old (as the kids say) when I learned that you can uncheck "Descendants must override" for a method in an interface. LabVIEW will then treat the interface code as a parent-class implementation, and let you call it. And even if you do override the method in the child class, if you typecast a child class object as the interface, you can call the interface code using the child class instance.
Again, no. This is not right at all. Please read the paper, I'll link it again: https://forums.ni.com/t5/Community-Documents/LabVIEW-Interfaces-The-Decisions-Behind-the-Design/ta-p...
Page 8. If an interface has method X, and the child has an override method X, casting to the interface will still call the child's implementation. Quoting from the paper- "No matter which ancestor wire that a given object is traveling on, method X always dispatches to the same VI for that object."
The only time the interface code is called is if the child doesn't implement that method.
Also... Java and C# both have default implementations for an interface, so if you think that's a "bad thing" then tell that to Oracle and Microsoft. This isn't something NI just came up with on a whim.
@TimBlaisdell wrote:
Replying to Quiztus2:
If it has functional code that doesn't need to get overridden it's not an interface.
Here are some resources for you that describe what an interface is, in OOP:
https://en.wikipedia.org/wiki/Interface_(object-oriented_programming)
https://www.reddit.com/r/explainlikeimfive/comments/ao5ug4/eli5_what_is_an_interface_in_programming/
English is not my first language but I don't see how your links support your statement on that Interfaces have to be 100% pure abstract. I think that is in the end up to the ones designing a programming language. There are no global laws on that, like on nothing.
I poked around a bit more, and tried to get a list of languages that use default implementations (or something very similar), and came up with Swift, C#, Rust, Java, Python, Scala, and C++ (I think that's more just multiple inheritance but I'm not a C++ guy). It also seems like it's something being actively added to at least some of these languages, meaning it's something a LOT of people have decided is a good thing. I could see why you think it's bad if you think typecasting the wire changes the dispatch call, but it's not the case.
