LabVIEW
Classes With No Private Data
I would have absolutely no hesitation in making them a library. This is the point of the library after all: keep common code together.
I agree that if you do not have any private data, you don't actually have an object. So a class does not make sense here.
A class with no private data is basically a library anyway. I wouldn't consider a library "overkill" at all. Might as well make it one. There are definitely times when you would want a class with no private data though.
For example, say you have a base object of "TemperatureConverter" with the methods "ConvertFromCounts" and "GetUnitString". You can then implement the child class of "Celcius" that implements both methods. Then you could pass a "TemperatureConverter" into your data acquisition code, and it would be able to return any units of data based on whatever you sent it. Not that I'd recommend doing that in this specific case, but it's an instance where it makes total sense to not have private data.
The "Search Unsorted 1D Array" has an optional functor input that you can use, which is basically just a class that implements an Equals function. (Note that this method uses some VIM shenanigans to inline the function at edit time, not regular object inheritance, but it's the same general concept).
@BertMcMahan wrote:
A class with no private data is basically a library anyway. I wouldn't consider a library "overkill" at all. Might as well make it one. There are definitely times when you would want a class with no private data though.
...
The "Search Unsorted 1D Array" has an optional functor input that you can use, which is basically just a class that implements an Equals function. (Note that this method uses some VIM shenanigans to inline the function at edit time, not regular object inheritance, but it's the same general concept).
Abstract Classes. But those are made with the expectation that the children classes will have private data of their own. I'd say there is a good argument to instead use an Interface (LabVIEW 2020 or newer).
@crossrulz wrote:
@BertMcMahan wrote:
A class with no private data is basically a library anyway. I wouldn't consider a library "overkill" at all. Might as well make it one. There are definitely times when you would want a class with no private data though.
...
The "Search Unsorted 1D Array" has an optional functor input that you can use, which is basically just a class that implements an Equals function. (Note that this method uses some VIM shenanigans to inline the function at edit time, not regular object inheritance, but it's the same general concept).
Abstract Classes. But those are made with the expectation that the children classes will have private data of their own. I'd say there is a good argument to instead use an Interface (LabVIEW 2020 or newer).
The Equals functor does not use abstract classes the way LabVIEW normally uses the term. To use it, you never need to inherit anything. The class with the Equals functor is not (always) expected to have private data, though it can. Give it a shot- you can make a class that doesn't inherit from anything with a single method, named "Equals.vi", that matches the conpane required. You can make this class sort anything you'd like- enums, pictures, whatever- not just a class.
The "Equals" function, deep down, can do injectable "equals" functionality one of two ways.
The first way is for the class that you're sorting to have a method named "Is Equal.vi". With those, you don't need to wire anything to the "Equals function" input. In that case, yes, the class has private data. You also don't have to have that class inherit from the Equals function. This is pretty unique, and was very confusing to me at first, but they do some clever tricks (my "shenanigans" comment above) with VIM's to replace the target function with the one from the class at edit time. This means you can't dynamically inject Equals functionality this way (without making another abstract class of your own).
The second method is to wire up any class that has an Equals method defined. In those cases, you can use a class as an injectable method to sort/search for something other than the class itself. For example, you could make your own "IsTheMantissaOfThisFloatEqual" class that compares two floating point numbers, and only checks if the mantissa (the whole number part) is equal. In that way, the class doesn't need any private data. The important part is, again, the class doesn't inherit from anything to implement the Equals behavior.
Thus, it's not an abstract class in the way LabVIEW normally describes an abstract class- as in, a parent class with little or no private data, acting more or less the same as an Interface. You could argue it's sort of an abstract class, in that it provides a conpane and a function name you have to use*, but object inheritance is not related to the functionality here.
I could imagine a use case though for needing private data for configuration reasons, but not for data handling reasons. For example, consider a class "IsFloatEqualWithTolerance". Normally, the Equals? function isn't used with Floats due to machine epsilon considerations. If you make your own comparison class, you could have "Tolerance" in the private data of the Equals function. Then you could do searches on float arrays with a given tolerance. Here, you'd need private data, but it's not private data that relates to the thing being sorted.
I'd also argue that, while using an interface here is perfectly functional, it's a bit confusing. In my mind (at least), Interfaces are designed to be inherited by something. The Equals functor isn't natively something that's inherited. If you're using an Interface to implement your Equals method, I'd assume this would need to be inherited somewhere.
To end my extremely tangential post, see the Help for "Search Unsorted Array":
*I'm not sure on the function name part, it might just need the right conpane.
