Ship common "Interfaces" for use in customer written shared code

[cbutcher]

Perhaps a future LabVIEW version can include NI-defined common interfaces (with ~1 method each).

Examples might include "Initialize", or "Dispose" (to borrow from C#). "Shutdown" might be another option.

This could allow different developers to all base their code on a set of common shared interfaces, and then users receiving their code (via VIPM, GCentral, etc etc) could use it as a plugin more easily.

[wiebe@CARYA]

>> That's like wanting to compare a string with an

>> integer! I don't think this has been asked for.

>Maybe hasn't been asked for here, but this is something that is necessary in some applications. LabVIEW already defines a canonical sorting of objects in different classes so that you can sort arrays of clusters that include LabVIEW Object or use any given common parent (including LV Object or any interface in LV 2020) as a key in a map. These are "handling data generically" use cases; there are also more app-specific scenarios where the comparison is needed.

One problem that arises with supporting this (overwriting operators for different types) is that it would require some sort of function overloading scheme. Sounds a lot more complicated to me. But if this would be possible, I wouldn't mind.

[MandatoryAlias]

@AristosQueue

I do believe there are enough existing models of interfaces in other languages that we could all agree that certain common interfaces are certainly viable.  Take dotnet for example:

IComparable

IEquatable

IEnumerable

IDisposable

IList

IDictionary

I agree that Initializable is a poor fit for an interface. 

Serializable may be too low down the object hierarchy, but I'm also not terribly concerned about that. 

The reality is that with interface classes, the must-override behavior delegates that code responsibility to the programmer and if they fail to properly serialize and deserialize their classes... well that's their problem.  Interfaces don't replace proper code design or testing.  And some of these lower-level, more-common interfaces can easily be implemented across the board without hurting anyone's feelings.

Oh and more importantly, there are already *classes* that provide these implementations in vi.lib.  Classes.  "Less Comparable.lvclass" must be the root object of every thing that wants to be sorted.  Sorry, I've got a job to do and it doesn't involve restructuring my code around that decision.  The classes in /vi.lib/Comparison must be an changed to interface classes.  I'm honestly shocked that NI shipped those classes and replaced my array pallet with a bunch of awful VIMs that accomplish nothing.  I can't even edit my pallet to bring back the primitive sorts because they don't occupy a file for the pallet editor to target.

[wiebe@CARYA]

> "Less Comparable.lvclass" must be the root object of every thing that wants to be sorted.  

To sort you don't need to inherit from that class. The sorting VIs are malleable VIs, and implementing the correct method (correct name and compatible connector pane) will allow sorting. This is polymorphism, not dynamic dispatching.

I agree an interface would be more appropriate.