DVRs of Interfaces

[Nathan-P]

Interfaces are new in 2020, and I'm just getting started using them. One thing that I find confusing is why LabVIEW forces Data Value References for interfaces.

I've found that, for interfaces, "Restrict references of this class type to member VIs of this class", this option is always enabled, and cannot be changed.  I want to know WHY did NI make this limitation for Interfaces?

I can work around it by making an "accessor" VI that returns the DVR in the interface, so it's not a big deal, I just want to know the logic of why NI felt the need to limit interfaces in this way.

[Bob_Schor]

You might find this video made by Stephen Loftus-Mercer and Allan Smith "interesting".  There are other sources about Interfaces in LVOOP on the Web.

Bob Schor

[DerrickB]

Allowing external entities to create DVRs of classes/interfaces is a form of breaking encapsulation; the class itself loses some control of how it manages the lifetime of itself which isn't really a thing at all for normal dataflow class wires. I would imagine removing that ability from interfaces is closing some sort of oversight when DVRs of classes were initially implemented. If a class (collectively meaning interfaces as well) is intended to be used by-reference and leverage the special treatment that DVRs of classes can have (cast up/down, property read/write on DVRs), the class should explicitly be written that way.

An option that is always available for less special DVRs of classes is to put the class instance inside a cluster and make a DVR of that cluster. Such as when a manager class wants to store an instance of a class along with other data in a DVR.

[Nathan-P · Accepted solution]

Found this document and was what I was looking for: 

https://forums.ni.com/t5/Community-Documents/LabVIEW-Interfaces-The-Decisions-Behind-the-Design/ta-p...