By value class store in DVRs vs By reference class using DVR as private data

[wiebe@CARYA]

---

@Loïc.W wrote:

---

wiebe@CARYA  a écrit :

If the class is by reference, you can't use it as you should, by value... The class is ruined.

wiebe@CARYA  a écrit :

For the record (but I think we're all agree on that) both by value and by reference would still mean by wire. I don't want Globals or singletons in OO of any sorts in my programs.

---

I'm a bit late about this but I do not understand why a "by ref" class cannot be used as the same way (for an end user) that a "by value" class.

...

I don't understand why qualify as "ruined" a "by value" class

So now I run my main. I spot a problem in a SubVI (that is open), and uses the class:

• With a by value class (and all other by value objects) , I'd stop my main, and run the SubVI. All the values are on my Front Panel. I can even Shift Drop the SubVI on a new VI, and get all controls with their current values.
• With a DVR anywhere, this is pointless. The DVR is gone. Sorry, no debugging.

Or I put a probe on the class, to debug it:

• With a by value class I'll see what's in it.
• With a DVR, you see 0x876543... That's not helpful. I guess I'll spend some time making custom probes...

So during the development, DVRs are very inconvenient to me.

Apart from that, DVRs come with strings attached. Every DVR you open, needs to be closed. Or you have a leak. Not a big problem. Unless you (or someone else) forget. Or simply don't know about DVRs. So now the class needs a manual with a warning in it... But who reads manuals?

Even more, everything by reference will be a potential source of race conditions. Invoke some methods in loop A, invoke some methods in loop B. You often should interlock both processes, as the class is by reference. This is never a problem for a by value object. You'd be forced to synchronize the data, which ironically is exactly what you try to when DVRs seem like a good idea. The upside of DVRs, that the data "communicates", becomes a downside. You now have to write boiler plate code to actually prevent the data communicating...

Anyway, suit yourself. I have no intention at all to convert anyone.

[wiebe@CARYA]

---

@Loïc.W wrote:

What's happen? The developer will not see that it is a "By ref" class and it will still work properly no?

Then if I tell the developer that it is a "By ref" class, he will use it as a "By refs" or a "By value" class depending on the situation. (/!\ race condition)

Wrong? (real question)

---

If you use a by ref class as a by value class, you'll get all sorts of problems. If you have a method +1, and you split the wire and call it on each wire, the results will simply be wrong. Both will be 1  for the by value, 2 for the by ref, or 1 or 2 if you don't synchronize the execution order.

Of course if you assume a by ref class, and it's a by wire class, you also get wrong results. So this is a matter of expectations, and what you're used to.

@Loïc.W wrote:

I don't understand why qualify as "ruined" a "by value" class

---

Well, it would be ruined for me. And for debugging.

It would be more code, more complexity, more strings attached.

@Loïc.W wrote:

About the purpose of this topic, I see now some use cases for storing an object into a DVR, but I think that I'll never have a situation where I must do this because I mainly use "By ref" class. (Society template with scripting tool)

---

Please tell. I'm sure there's a by value alternative.

Anyway, OP didn't want to go into this. We're hijacking the thread.