Jim Kring

I thought that everyone uses LabVIEW because it's fun Saving your money to spend elsewhere is a great idea (BTW, VIPM Enterprise is going to be released very soon ) Cheers,

Here's my heavily-biased weigh-in (disclaimer: I'm on the team that created VI Tester): I haven't used NI's UTF (but I've seen it demo'ed). It seems to have great features for knowing whether you are testing 100% of your code and need reports to prove it. Of course, I have used JKI's framework, which is great if you're interested in using a proven software engineering architecture (xUnit) for software testing that's implemented in LabVIEW, for LabVIEW developers, by LabVIEW experts who use it themselves to write and test commercial software products written in LabVIEW. With VI Tester, writing unit tests is fun, since all your tests are written in LabVIEW. This also means that you can reuse code within your tests, and employ object-oriented techniques in the design and implementation of your tests. JKI uses VI Tester for testing all the software it writes and we're going to keep making improvements over time, including possibly integrating it with other products like VIPM's package builder (JKI currently uses VI Tester to automatically run unit tests on all our VI Packages [software reuse libraries] during the build process). Update: I'll also add that there is a wealth of information (book, websites, etc.) on xUnit, including: test architectures, design patterns, best practices, tutorials, etc. This means that there's a wealth of training materials that apply almost directly to how to use VI Tester. Thanks, -Jim

I would only do this in cases where I know that specific data inside the parent needs to remain locked while child methods are being called. This is, of course, very tricky and one would need to watch out for other deadlock possibilities. Maybe this would work, but it would require putting a parent method inside an IPE structure on the child method's block diagram. This could result in a deadlock, so you'd have to be very careful (similar to if you create a special Semaphore for the first case, above). Yes, I agree with you. It's all about trade-offs. Personally, I find the DVR-inside-LVOOP solution to have the least development overhead in the widest number of use cases (I especially like that dynamic dispatch can work on any method, unlike with DVRs of LVOOP objects). In those cases where we need locking at all levels of the inheritance hierarchy, we can either put class methods inside IPE Structures and be careful not to deadlock or use an external locking mechanism and be careful not to deadlock.

Hi Tomi, Thanks for the detailed analysis. Here are my thoughts: In cases where a child wants to: lock, read parent private data, perform calculations/work, write to parent private data, and then unlock, I would set up a Semaphore/lock specifically for that transaction - i.e. I would not rely on the IPE structures or DVRs for ensuring that the transaction is atomic. Regarding deadlock, I'm pretty sure that you can avoid this altogether by ensuring that class methods do not ever put methods of their own class inheritance hierarchy inside of IPE structures used to operate on class data. Did I miss anything? Thanks,

You're not missing anything - LabVIEW is.

Thanks for sharing this story. On my side of things, I've been frustrated by the lack of usability features in LabVIEW related to LVOOP. It makes me happy to know that you've been fighting the good fight. Please let us know how we can help.

One thing that I've started doing with the DVR-inside-LVOOP scheme is using an IPE Structure to (un)bundle the DVR reference outside of the IPE that (de)references the private data. I like this a lot because it keeps the object/reference/data wire in straight line without any branching -- it seems to have the best "style". Note that I named the DVR "ref" to keep the (un)bundle nodes small in width. What do you think?

I thought that this JKI RCF plugin was so cool that everyone needed to see it. Thanks, Jeffrey for this cool tool!

Hi Kurt, I'm happy to hear you say this, since I've come to the same conclusion while talking it over with other members of my team. IMO, the value of being able to Dyamic Dispatch any method, regardless of whether it's a by value or by reference method, without having to create special, duplicate by reference wrapper methods around dynamic by value methods is huge. The only downsides (that I can see) of using the DVR inside an LVOOP object are: 1) You can't tell just by looking an an object that it's by reference (as you can when you see a DVR with an LVOOP object inside) 2) You have to unbundle the DVR before you can pass it into a IPE Structure Oh, and there's one situation that you also have to be very careful for: If you're inside a child method and you call a parent method inside an IPE structure, you might deadlock if the the parent method is itself, or calls inside of it, a dynamic dispatch method that results in child method being called. With this in mind, one feature that I'd love to see in LabVIEW is for IPE structures to be smart at run-time and output an error (rather than deadlock) if an IPE is called inside another IPE and tries to dereference data that has already been dereferenced by the outer IPE. Cheers! I see that you posted similar thoughts, just as I was typing up my reply to Kurt, above Cool! It seems that we're all starting to converge on the preferred methodology (pun appreciated but not intended) for by ref OOP in LV2009. I guess that I would add that if NI were to implement either the ability to dynamic dispatch on methods with DVRs of objects OR the ability to wire a DVR of an object into a by value method (dereferencing/referencing behind the scenes) then I would probably migrate over to DVRs containing objects, rather than vice versa. But, until then...

Hi Kurt, I've been looking at your example reference classes (Bike+Racer) and I'm starting to second-guess my decision about wanting to put the DVR outside the object (rather than put the DVR inside the object). I how your example (DVR inside the object) allows dynamic dispatch at the public method level (instead of having a static, by reference method that wraps a protected, dynamic, by value method -- this creates a lot of extra methods). However, one thing that makes me uneasy about putting the DVR inside the object (as your example does) is that each level of the inheritance hierarchy has it's own DVR and is locked/unlocked separately. I worry that this could cause some nasty race conditions or deadlock -- have you thought about this? And, an attempt to remedy this issue takes us back to where we have a lot of framework/support VIs for each class. Cheers,

Agreed. I posted this to LAVA so that I could edit my idea yep, I'm gaming the system I've closed this topic. Please discuss in the Idea Exchange thread for this request.

I agree that the class should wrap a DVR to a cluster, but rather the DVR should wrap the class. However, I'm not sure that I agree that we need dynamic dispatching of reference terminals. I think that I would prefer to be able to pass an object reference into a by value method and have LabVIEW automagically dereference and re-reference the object behind the scenes -- almost list wrapping the by value method in a IPE Structure on the block diagram of the caller that is using an object reference.

I believe that the default value of the class Inheritance setting "Restrict references of this class type to member VIs of this class" (which is new to LV2009) should be FALSE. The default value is currently TRUE. I feel that the default value of TRUE adds an unnecessary constraint on users of value objects, which limits their ability to program applications. Here is my argument: There are two use cases for DVR's to LVOOP objects: Use Case #1: DVR of a Value Object A DVR of a value object (VO) is simply a DVR to a VO instance that is created by a user of the class in order to facilitate synchronous access to a VO from multiple locations of their application. In any case, a VO class designer does not care whether users of the VO create a DVR to facilitate memory management or parallel access to the VO and the the "Restrict references of this class type to member VIs of this class" setting should be set (and ideally default) to FALSE. Use Case #2: Reference Object A reference object (RO), by my own definition, is an instance of a class that was designed/intended to be used only in a by reference fashion. Such objects usually have setup and teardown (create/initialize and destroy/uninitialize) requirements that should be under the control of the class designer. In such cases, the "Restrict references of this class type to member VIs of this class" is very useful and should (IMO) be explicitly set to TRUE by the class designer. However, by assuming that all classes should have this value set to TRUE, it assumes that all classes are intended to be used by reference. This restricts use case #1 by default, even though it has no requirement on how the VO is created or destroyed. Thanks for listening

My thinking: LVOOP objects are "data values", so a DVR to an LVOOP object is an object reference.

I have a feeling that people will/should just call this "native OOP" or "LVOOP" and start refering to DVR's as "references" (and DVR's to LVOOP objects as "object references"). This is the "right" (sanctioned) way to do OOP in LabVIEW, so there's really no need to qualify it. But, if you must qualify it, then the term "native" seems fitting.

It might be a good idea to have (re)design discussion in a more public setting (like the idea exchange or here on LAVA) prior to reaching the beta phase, since: It's harder to change something that's already implemented The time window for the beta program is relatively short The conversation isn't visible to a wide audience Of course, the flip side of it is that you don't get real usability feedback until people can actually use the feature (when it hits beta). I guess that I would also add is that it would be great if features like this would have a setting/option that allows users to revert to the original/legacy behavior. And, I think that this is one of the guiding principles of the new annual release cycle of LabVIEW -- features should be implemented in such a way that allows them to be switched ON/OFF, based on whether they are ready at the time when the product is scheduled to ship. I hope this is helpful Thanks,

After playing around with the new probe watch window, I'm on the fence about it. I find it useful to have a centralized location with all my probes, but I also find it to be "not the way I'm used to doing it". I sort of think that I'd like the best of both -- have a probe watch window that shows all the probe values but optionally let the probes float freely, by default.

I agree completely -- I really don't like the probe watch window or the fact that all new probes are automatically added to this window. I recommended adding this to the LabVIEW Idea Exchange.

I talked to Darren in the hallways, here at NIWeek. He said that we can easily create an RCF plugin that calls the VI that performs these scripting actions.