[Joe Ross]

Originally Posted by Greg McKaskle

Other techniques for structuring your code is to look at using object classes. Object classes in LV are a powerful mechanism for code extensions and organizing things in larger teams. It allows for exposing some fields and hiding others so that subsystem complexity is more manageable. The most interesting thing about LV objects is that they are by value. Most languages use new foo() to return a pointer to a foo. Each piece of code that is handed the foo pointer interacts with the same foo. This makes some things easy, but parallelism quickly introduces errors. In LV, the constructor returns a foo on the wire. When the wire is branched or stored in a global, each is its own copy. This means that unless they contain a refnum, they are independent and can be operated on in parallel without introducing the same sorts of bugs. LV does the same thing for arrays and strings. Anyway, for most FIRST teams, I don't know that the code grows large enough to need to use object class mechanisms in order to manage complexity, but it is a useful technique nonetheless, and if a team wants to investigate it just to learn, I am certainly willing to assist.

I was under the impression that Labview object oriented programming wasn't supported in our version of LabVIEW RT (although later versions do support it). Was I wrong? Some of the stuff we do would be a lot simpler to implement as a class.