Interface Cluster

[RogerSaele]

In OOP, interfaces define a contract. When a method/function expects a type of interface as an argument, any type implementing this interface can be passed. A well known and much used concept. I imagine something like this could be implemented for clusters in LabVIEW. Imagine if you could have a subVI define a cluster/cluster array, mark it as an interface and be able to wire any cluster/cluster array that adheres to this interface (adhering to the interface would basically mean that an unbundle by name node accessing any/all members of the interface would also work on any “derived” cluster). Both the cluster on the front panel and the wire should clearly indicate that this is an interface, which would mean that the cluster/wire actually contains more members, but you only have access to the ones defined by the interface. I definitely see some use cases for this. Sound useful/feasible?

[wiebe@CARYA]

When would you need this? And in those situations, wouldn't a parent class ('interface cluster') with child classes ('derived clusters') allow this already?

---

@RogerSaele wrote:

Sound useful/feasible?

---

Useful? Not sure.

Feasible? Probably not, but not my call.

A .vim would be able to do accept 'derived clusters', but that doesn't (completely) diminish the idea...

[RogerSaele]

Yes, OOP solves this. But I presume LabVIEW developers do not use OOP everywhere. Some even advocate against OOP as a concept altogether (not saying I do, I actually like OOP and use it extensively). A non OOP solution to a problem should not be disregarded because an OOP solution exists, IMHO.

For example, I want to be able to do unbundle by name in a subVI and use this VI with different clusters as inputs. Let's say all clusters have a "parent tag" string, for instance. I don't see how this can be done with malleable VIs, but I might be wrong.

[wiebe@CARYA]

>I don't see how this can be done with malleable VIs, but I might be wrong.

A .vim will accept anything. If you put an unbundle by name in it (unbundle "parent tag") the .vim will break if you wire a cluster that doesn't have a parent tag element. Additionally, you can force the "parent tag" to be a string.

[RogerSaele]

A .vim will accept anything. If you put an unbundle by name in it (unbundle "parent tag") the .vim will break if you wire a cluster that doesn't have a parent tag element. Additionally, you can force the "parent tag" to be a string.

---

Oh, indeed. Declined it is then.

[wiebe@CARYA]

>Oh, indeed. Declined it is then.

Not per se. Malleable VIs are not that practical. All inputs will become adaptable, and the entire chain up to the sub VI need to become .vims. So they 'solve the problem', but might cause a lot of damage while doing so.

This idea would be some sort of 'any cluster' type, making it a malleable input\output. A mix between OO polymorphism and malleability.

It's worth watching how many people will like it, and to hear about feasibility.

[AristosQueue (NI)]

Weibe: I am not a fan of this idea at all. It is exactly the sort of weak-typing that I believe does more harm than good in the JavaScript world. It would work technically. But adding this feature would argue that naming a field of a cluster "X" is good enough to say, "This cluster fulfills the contract for all clusters that happen to have a field of the same name and compatible type." That's far too casual in my observation. It leads to a lot of invisible coding conventions.

A malleable VI explicitly announces to the world, "I'm going to contort myself to whatever you give me." It's a different beast than a plain VI. Giving that level of malleability to all VIs would spread the weak-typing out of a deliberate location and into more general locations.

I know that's a weak argument against this idea... it is so close to stuff I've already said I support. But to me, this would be a bridge too far. The line between a strongly-typed language that kills its users with straightjackets and a weakly-typed language that will compile anything and pretend it is valid code is obvious. The line between reasonable relaxation and soggy type mess is much less clear, so I expect lots of different opinions here.

[wiebe@CARYA]

@AristosQueue :

I concur. I'd prefer a more rigid malleable VI (where not all inputs adapt, and\or adaption is more restricted) to a new looser general input. (Give them a finger... )

[AristosQueue (NI)]

wiebe: You can constrain any inputs you want in existing VIMs just by using the Assert Type Match node in the VIM (or any of the other Assert nodes in the palettes).

[wiebe@CARYA]

>wiebe: You can constrain any inputs you want in existing VIMs just by using the Assert Type Match node in the VIM (or any of the other Assert nodes in the palettes).

I'd still have to wire something to see it fail...  It's not always clear what you can\should wire without trying. At least (of course) not as clear as with a VI. When two wires are connected internally, it's not always easy to see which connected wire is wrong (both will break).

VIs are like solid blocks of lego, VIMs like clay. I'd want parts lego, part clay...