RogerI wrote:
Do you know if there is any LV reference based oop in progress at NI?
For the record, I'm the lead architect for all the OO features of LV. The Data Value References released in LV2009 are our solution for references and will be the full extent of reference support you should expect in LabVIEW. The DVRs solve the dining philosophers problem that single-element queues were succeptible to when multiple of them were used in conjunction, they provide init and uninit bottlenecks for LV classes, and they can help control data copies. Various requests for extension of the feature have been heard and generally rejected for the next several years. The most common request is the wiring of DVRs of classes directly to subVI terminals meant to accept class wires directly... "Why do I have to wrap my subVI calls in an Inplace Element Structure every time I want to access the reference?" The answer is two fold: Primarily having the user explicitly control the length of time that the reference is unlocked (via the structure) encourages the design of APIs that avoids race conditions when multiple operations need to be done in sequence without parallel operations intervening (such as setting multiple properties in the object). Secondarily, there are some situations where a node has multiple output terminals of the class type where it would be ambiguous which one should be the one put back in the reference. The secondary case is far far less important than the primary. If you want to design a class that is meant to be used by reference, that's straightforward... just implement all the methods as operations that take the reference and use Inplace Elt Struct on their diagrams. Include protected-scope dynamic dispatch methods for things that you want child classes to override.
If all of this seems "not exactly easy to use", that's intentional. In a highly parallel language such as LabVIEW, references are extremely dangerous, leading to a whole host of hard-to-debug bugs. Reference classes should be used very rarely -- I'm sticking by my estimate of no more than 5% of all classes out in the world should be by reference, and most users shouldn't be needing them at all. In the vast majority of customer apps that I have looked at -- and I get called in to review many of them -- the code can be completely rewritten without references to the classes, resulting in fewer bugs and much higher performance. The higher performance comes because a) you get rid of the mutex overhead and the cache-line hits of the references and b) the LV compiler can do optimizations with by value types that cannot ever be applied to references.
I personally do not see the low levels of support for references as a drawback for LabVIEW. Rather, we are one of the few languages that can really take advantage of the multicore environment that most computers are becomming, and as time goes by, I expect more and more algorithms previously written to use references to change to not use them so that they can be made more parallel, and spending our time improving and optimizing the by-value cases is much more important to the future growth and adoption of LabVIEW.
Having said that, we do listen to our customers, a lot, and if after a couple years we see that there really is a need for more reference support than the DVRs supply, we'll add them. At the moment, we think we've got the right levels (baring bugs like the one you found). I hope the OO features we have today have improved your LV experience and helped your programming. Please keep providing feedback and we'll keep doing our best to make it better as time goes by.
