In March I attended the Certified LabVIEW Architects Summit (CLA Summit) in Austin, Texas. Every year National Instruments hosts this conference where CLAs can network, discuss best practices, and share ideas. This year the theme was Continuous Improvement: Building Better LabVIEW Applications. Below I share an original narrative borrowing thoughts on a couple presentations I attended. One was given by Dmitry Sagatelyan, who discussed multiple inheritance and LabVIEW limitations. His presentation can be found here. I also borrow from Chris Cilino whose code and video of the LabVIEW Data Container can be found here.
My recent work has included a hardware-in-the-loop simulator. This project required that I model the ecosystem of a forest in Eastern Australia. I was making my way quite successfully through the requirements implementing class after class of various plants and animals. I was quite pleased with myself delivering a very large HiL system several weeks ahead of schedule and thousands of dollars under budget.
Using inheritance, I was able to reuse much of the code I had used before. Though animals native to that part of Australia are unique, I was able to reuse the ancestor classes such as mammals and birds. Things were going well, until requirement 10.3.2 which read: “The ecosystem shall have platypuses. The number will not be known until run time.” I set out to create a platypus class inheriting from the classes of beaver, duck, otter, and snake.
This created a problem. LabVIEW does not allow multiple inheritance. If class C inherits from A and B, which method from the parent wins? To avoid this, LabVIEW disallows multiple inheritance.
Suppose LabVIEW did allow multiple inheritance. I could then create a platypus by inheriting from the beaver, duck, otter, and snake classes. I would also have a platypus that is capable of flying as it inherits from duck class. The absurd notion of a flying platypus might be seen as a bug to the user and I would need to spend some of the time that I saved using inheritance (reuse) to ground the platypus.
Due to this limitation (or should I say feature?) in LabVIEW, as LabVIEW developers, reusing code is not as easy as allowing our new class to inherit from an already productive member of society. Instead, we have to work around that.
This is where I propose Chris’s LabVIEW Data Container could prove useful. Think of the data container as a hierarchical list of variant data that can be navigated both ways. Data containers can contain and point to other data containers—both parent and child. What if the data container could be implemented as other languages implement traits? What if the data container contained class references or references to public methods within them?
Stay tuned…
