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.

[AristosQueue (NI)]

What would the conpane for Initialize be? Or any other method?

You cannot design an interface without knowing the intended caller. What you're asking for is VISA or something just like it. There's a risk with such standards: a common interface for all hardware falls apart as soon as a piece of hardware has new capabilities the interface never dreamed of. It's tricky to manage such a "universal standard" for systems to plug into.

I don't think this proposal has any viability in this general form, but if it does, it is -- in my opinion -- a proposal you should make to the IVI Foundation, not NI directly.

I'm open to arguments for the community that I'm wrong.

[prettypwnie]

I think a good idea for a built in interface would be a "Comparable" interface with a required override "Equals" method (maybe also "Less Than" and "Greater Than" methods?). Then any class could implement inherit (I'm trying to learn this new lingo!) from Comparable and use equals methods. Basically, the interfaces version of the equals VIM that already exists.

[cbutcher]

@AQ:

I think for all of the methods I suggested, it would probably need to be only class in/out, error in/out in line with the static/dynamic dispatch templates.

For Init, I can see this gives some problems - if data was needed you'd presumably need to store data inside the class before calling Init, requiring some sort of factory method, and if you already had that, you might as well call the Init method inside the factory (meaning no interface required).

It would allow an object to be stored "uninitialized" somewhere for a while and then Initialized later (or by a different caller, etc). Still, whether this can be a) useful or b) called Init, I'm less sure.

You could also of course use it for classes that didn't require data to initialize (perhaps in the same style as a first call based method?) but I would guess that's a minority of the classes a typical developer would want to "Initialize".

Hopefully for the others, it's a bit less objectionable?

@prettypwnie,

I sort of like the "Comparable" idea, but I don't know how it would be implemented by a given class. If I inherit from your Comparable interface, I'm saying presumably that I can be compared with all other objects inheriting from Comparable, which might be completely unrelated (especially in the general, interface created by NI and then inherited by lots of different developers case).

Perhaps a "Serializable" interface could solve a similar issue? If you can have your class convert itself to a nice string representation, then those could be compared and/or sorted. Of course you can use Flatten to String or similar now, but the result might not always make it sort in the manner you wanted.

However, if we had a "Serializable" interface, I'd probably want an "Unserialize" or "Deserialize" (?) method to also be included - and really that would operate on a string, not an object, so it wouldn't be a dynamic dispatch member but would need a specific implementation in the (NI-provided, in this scheme) interface. At that point, there would need to be some rules about your serialization to give it a chance of working more than just erroring on every serialized object. Maybe if you said the first part of the string must always be the output of Get LV Class Name (or if you used the Template method to implement "Serialize" as a static dispatch method and had "Serialize Core.vi" as the dynamic dispatch must override, then have a Deserialize (unserialize?) Core method for DD that could be run on the input from Get LV Class Default Value by Name.

Would that work for you? (and do you think it could be shipped by NI, or is just too specific to an individual "customer"/situation/application?)

I kind of like it, if it could be made to work. AQ already has a "Character Lineator" that by using an Interface rather than a Class might get you most of the way, but I haven't used it to be sure of how it works...

[AristosQueue (NI)]

> that by using an Interface rather than a Class might get you

> most of the way, but I haven't used it to be sure of how it works...

A bit of warning: Do not try to do serialization with an interface instead of a class!  I've already been down that road. 🙂 The chat for the Character Lineator discusses that point in detail. Serialization MUST be a class... you cannot inject serializability at a lower-level of inheritance because if the parent doesn't serialize its data, you cannot restore the object's state.

[AristosQueue (NI)]

prettypwnie: I am vacillating on whether compare can be an interface instead of a class. Does it make sense to inject comparability at a lower-level of the hierarchy? Or does it hit the same logical problem as the serialization? Unlike serialization, injecting comparison doesn't result in malformed objects, but is it a desirable thing? I've wavered on this point.

[prettypwnie]

Hmm, I guess when I really think about it I'm not sure whether comparable should be an interface. cbutcher has a good point that different classes might not really be comparable with each other, so then it gets confusing.

[AristosQueue (NI)]

prettypwnie: there are several models in other languages worth evaluating.

[wiebe@CARYA]

>Hmm, I guess when I really think about it I'm not sure whether comparable should be an interface. cbutcher has a good point that different classes might not really be comparable with each other, so then it gets confusing.

Why would you want to compare different classes? Or rather, why would I want to compare classes that are not in the same hierarchy? That's like wanting to compare a string with an integer! I don't think this has been asked for.

If I create an object of my class, it would be nice if I could compare it with a second object of that class though. What the compare would do is up to me. But two objects can be 'equal' to me, as programmer, but not equal to the build function.

It would be even better if all functions depending on the Is Equal? and Less? compare (Min & Max, Sort 1d Array, other compare functions) would automatically be available.

We can do this, kind of... If all functions where wrapped in .vims, and those .vims had a type specialization case that used methods defined in an interface... Now if those interfaces where standard, eventually the build in functions could adapt to them, eliminating the need for the .vims.

[AristosQueue (NI)]

> 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.

[AristosQueue (NI)]

> Now if those interfaces where standard, eventually the

> build in functions could adapt to them, eliminating the need for the .vims.

Check out the directory "vi.lib\Arrays" for some not-in-the-palettes-(yet) VIMs that show the direction that I'm steering this topic.