Community Documents

Showing results for 
Search instead for 
Did you mean: 

LabVIEW Interfaces: The Decisions Behind the Design

Interfaces are a new part of the G language in LabVIEW 2020. Interfaces exist in other object-oriented programming languages as a companion concept to classes. This document explains the reasoning LabVIEW R&D used when deciding how interfaces should fit into G. It not only discusses where we mimicked other languages and where we did something different but also why we made those choices. The aim is to help our customers adapt training materials from other languages to the LabVIEW environment and to teach users how to work with our design instead of against it.

The document assumes that you are already aware of what an interface is and how they work in LabVIEW.

You may want to review the shipping documentation and example programs before reading further. Reading this document in order to learn how to use interfaces is likely to confuse you. It is going to cover alternative designs that we did not implement and discuss corner cases that 99% of users will never ever see.


This document is a follow-on document to the 2006 document for LabVIEW classes:

LabVIEW Object-Oriented Programming: The Decisions Behind the Design


The video introducing G interfaces can be watched here.


-- Stephen Loftus-Mercer (aka Aristos Queue)

LabVIEW R&D, Principal Software Architect

National Instruments, April 2020

Active Participant
Active Participant

Hey AQ, thanks for taking the time to write up this white paper.  I've not had enough time with LV20 and LV's Interfaces to fully understand everything yet, but I hope to get there soon.


My question is regarding the last section, "No Scala Traits."  There's a lot of different functionality included in Scala traits, some of which *are* included in LV Interfaces.  (Okay, a default implementation is the only thing I can think of off the top of my head--but that's one!)  Can you be more specific in what features you purposely left out? 


I know at one point there was much discussion about defining private data in LV traits/interfaces.  FWIW, I'm glad that hasn't happened.  I also remember having extensive conversations about how we could allow default trait/interface implementations to access a child object's private data.  If I'm reading the paper correctly, LV interfaces don't provide a way to do that.  Is that correct?  Or would it work if the Interface author defined protected data accessors as part of the interface to be implemented by the class author?


Thank you for the description.
It will serve me well I think in first making better decision when architecting a (greater) LV software and second when discussing/explaining LV interfaces (and objects) to people having a solid OOP background from say C# or something similar.
Especially the point that a child class doesn't need to overwrite methods of interfaces if the parent class does already was new to me and seems interesting. It gave also insight into my question what happens/how to deal with the question if one class inherits two interfaces each having a method with the same name.