Value vs. Reference based Classes

During NIWeek, I talked to a few customers about the new OO feature in LabVIEW 8.20 (see previous post). I was surprised by how many of them were upset that the design was value based instead of referenced based, so I thought I would add my 2 cents to the debate and explain why it's a great idea - although you do really want both available to you. However, as there are other implementations of referenced based OO in LabVIEW, the new value based approach was the right first step, in my opinion.

So let's first do some definitions:

Reference Based

A referenced based architecture is similar to how objects are handled in .NET and Java - whenever you have an object, you only get a reference to it - something that points to the actual object. This means that multiple parts of your code all refer to the same object - allowing global updating...that's important for this discussion.

Value Based

A value based architecture is more how stack-based objects in C++ (or ValueTypes from .NET) are handled - when you hold onto an object, you have sole possession of the object and any changes you make are not visible to anyone else - they would have a copy, not a reference to your instance.

Real World State

So, how does any of this matter? Well, the issue is very similar to the imperative versus functional programming debate that I've talked about before (see the Lang.NET posts for starters).

For example, the complaint I was hearing about the value based design was that it couldn't capture real world state. If I were to create a LV class to represent throttle, the copies would mean that real world changes would not be reflected (ignoring whether or not you embedded a reference inside the value base class). In these cases, you are correct - a value based class is not the right architecture for anything representing global state.

How Much Real World State Do You Have?

Now, don't get me wrong - that is a valid issue, but misses part of the picture. How much of the data in your program is truly global state? If you capture a waveform, is that real world state? In a way - but more importantly, it is a snapshot of the way the state was. This can be copied easily (ignoring the valid issue of performance of large data sets) and has no need to be globally represented. And what do you get for this? FREEDOM!

With the value-based semantics, you avoid the dreaded concurrency issue that imperative languages must always face. This design frees you from having to introduce locks and semaphores, wait conditions and events, explicit thread commands and all the other pain that you get in C++/C#/Java. It's dataflow!

Summary

The value-based semantics of the LabVIEW 8.20 OO design is a great solution, in my opinion, for representing non-global state. Examples are historical state information (even "just a second ago") and data types (complex numbers, matrices, etc). Reference based semantics are what you need for true global state (such as where the changes implemented by you have side-effects, like starting an engine, but I'm sure you can think of others), but involve the complexity of concurrent access protection.