My preference is to always lead with by-value where it works. Another way to think of this is that by-value is communication on a data wire where as by-reference is a tag based communication method (in some situations). These strongly overlap with data communication. (This may differ from a classic computer science definition but my main concern is the behavior I see, perhaps a different term is required but stay with me!) When you make changes they might affect other components that don’t have a dataflow dependency and if you read it twice in a row another piece of code could have changed it.

By-Reference: The data of is stored in one memory location.

Branching the wire risks creating a copy. There is also no way another piece of code can change the data on the wire.

By-Value: If you take a wire/data in LabVIEW and change it then it changes only for that piece of code and the code that is dataflow dependent on it.

I like to think of them at this level as how data behaves rather than definitions of implementation. Lets first define my interpretation of these items. I have been thinking about the techniques and analogs to these lately anyway so this is a bit of a meaty article covering the options that I see for implementing these and some thoughts on how they fit into teaching OOP.

We do more by reference work in non-OOP LabVIEW than we sometimes like to admit.

This causes a clash when people have learned OOP from these languages.

In “classical” OOP languages everything is by reference but in LabVIEW OOP is by value.

I think there are two reasons that these are tightly linked to conversations about OOP. by value which often come up when talking about OOP. After my previous post about Learning LabVIEW OOP there were some comments on by reference vs.

Use labview