LabVIEW
LVOOP with DVR - Best Practices and Caveats
Best practice (IMHO): Avoid DVRs at all costs.
They are a pain, as they get disposed when the code stops running. So you can not debug sub VIs.
You talk a lot about why\why not to use DVRs. You should tell us what you want instead. Better jet: show us the design. OO Programming should be preceded by OO Analysis and OO Design, at least for best results.
If you want singleton behavior, I'd consider a private global in a class. It won't avoid race conditions, but at least the data is still there when you stop your code. It's all very dependent on the situation, so we need to know about that. You can also wrap the FGV in the class, but do make it private (or at least protected).
For me, a DVR in a class is a "by reference" pattern. You shouldn't use patterns (like an actor pattern 
) as a solution to everything. Use when needed...
Search LabVIEW like a graph! 
I'm not sure what you want or need exactly, but if you have identified that you need a by-ref solution, then I suggest you check out G#. It adds reference-based class support to LabVIEW, and it has a powerful debugger (to inspect the internal DVRs). G# also supports standard LabVIEW-native-classes.
If I imagine what you are after, I can see similarities with one project where we had an application that sampled lots of data on many channels, these were stored to tdms-files, but some parts (a buffer for the most recent time) were kept in DVRs (G#-classes) and sent through computational "filters" or analyzing algorithms (and that result was also kept in DVRs), and then the GUI could subscribe to those feeds. It works like a charm and with very high performance.
G# is found in VIPM
wiebe@CARYA wrote:
Best practice (IMHO): Avoid DVRs at all costs.
They are a pain, as they get disposed when the code stops running. So you can not debug sub VIs.
You talk a lot about why\why not to use DVRs. You should tell us what you want instead. Better jet: show us the design. OO Programming should be preceded by OO Analysis and OO Design, at least for best results.
If you want singleton behavior, I'd consider a private global in a class. It won't avoid race conditions, but at least the data is still there when you stop your code. It's all very dependent on the situation, so we need to know about that. You can also wrap the FGV in the class, but do make it private (or at least protected).
For me, a DVR in a class is a "by reference" pattern. You shouldn't use patterns (like an actor pattern
I think this is a bit of an extreme. DVRs are a valuable tool your the toolbox. They can be abused like any other thing can but they are also very useful. We use them often. For me the decision to using a by reference to a by value class comes down to what exactly am I representing and whether the wire might get branched. If I am representing a physical item in the real world I prefer to use DVRs if I need to maintain state information about that item. The last thing I want is to branch a wire somewhere and all of a sudden my nuclear reactor is both on and off at the same time because the branch effectively cloned my reactor and now I have two copies of it.
@Mark_Yedinak wrote:
wiebe@CARYA wrote:
Best practice (IMHO): Avoid DVRs at all costs.
They are a pain, as they get disposed when the code stops running. So you can not debug sub VIs.
You talk a lot about why\why not to use DVRs. You should tell us what you want instead. Better jet: show us the design. OO Programming should be preceded by OO Analysis and OO Design, at least for best results.
If you want singleton behavior, I'd consider a private global in a class. It won't avoid race conditions, but at least the data is still there when you stop your code. It's all very dependent on the situation, so we need to know about that. You can also wrap the FGV in the class, but do make it private (or at least protected).
For me, a DVR in a class is a "by reference" pattern. You shouldn't use patterns (like an actor pattern
I think this is a bit of an extreme. DVRs are a valuable tool your the toolbox. They can be abused like any other thing can but they are also very useful. We use them often. For me the decision to using a by reference to a by value class comes down to what exactly am I representing and whether the wire might get branched. If I am representing a physical item in the real world I prefer to use DVRs if I need to maintain state information about that item. The last thing I want is to branch a wire somewhere and all of a sudden my nuclear reactor is both on and off at the same time because the branch effectively cloned my reactor and now I have two copies of it.
Sure, if you don't like debugging... And love those in placement structures.. DVRs are great.
How about OpenGDS by reference class if you want a by reference class? Last I heard, they are persistence, and you get by reference behavior for free. Will check that soon...
How about OpenGDS by reference class if you want a by reference class? Last I heard, they are persistence, and you get by reference behavior for free. Will check that soon...
AFAIK (Open)GDS does not register the objects, thus cannot be debugged. That could have changed though, it was some years ago I checked. A core concept of G# is that it registers the objects and thus they can be debugged. It even supports remote debugging (used for RT-targets e.g.), and the debugging events are logged and even shows up in DETT (desktop execution trace toolkit). It also has a an active debug mode to debug classes without the need to write an application to create objects. G# objects also has a method to create objects in an external process (separate thread), if you want them to be persistent. Very convenient for dependency injection.
@AYanez wrote:
@wiebe: "You talk a lot about why\why not to use DVRs. You should tell us what you want instead. ".
I am not against to use LVOOP by reference, but where I work there is not an architect and I have doubt about what is the best option. Until now I have only worked with by value approach and dynamic dispatch is great so I want to keep this functionality if it is possible. I hope you can give me tips to solve the problem of the best way.
Still not sure what the problem to solve is. Haven't looked at the code yet.
I have 306 classes in my current project, and none is by reference. Actually 1 has a DVR. I can switch it to by wire, but somehow it's less efficient for LabVIEW. Pretty sure that there are no copies and such. At some point I will refactor that one out (switch to the by wire child and delete the by reference).
It is possible to avoid by reference classes altogether.
It is probably also possible to only use by reference classes.
One thing to realize is the problem by reference classes try to solve, can actually cause problems as well. Problems by wire classes don't have (and why I use them).
One good example is the file reference library (not a class, but by reference non the less). The by reference is very convenient. You can read and write anywhere. But if there's a dialog that changes settings, you can't write them directly to the reference, because you want the user to press OK first. So now you have to start synchronizing things, because of the by reference construction. By wire doesn't have this problem, but the distribution is a problem. So once the dialog changed it's (copy of) settings, you'll need an event\queue\etc. (even a global would work) to communicate to the parallel threads using the data.
I prefer to stick with one paradigm. I know others who always use by reference.
I prefer by wire, because all normal data in LabVIEW is by wire. It's closer to the data flow paradigm.
