LabVIEW
By value class store in DVRs vs By reference class using DVR as private data
If the class is by value, at least you can use it as it should be used, by value.
If you really need to, you can put in in a DVR.
If the class is by reference, you can't use it as you should, by value... The class is ruined.
DVRs are almost never needed. LabVIEW is a dataflow language, and DVRs usually cause more problems than they fix.
Of course, this is heavily biased (towards proper wireflow practices) 😋.
Search LabVIEW like a graph!
@Loïc.W wrote:If I'm understanding well, with this method we lose the dynamic dispatch and cannot use directly the methods of the class... (But a property node works?! Wtf ?!)
You really loose DD at all, you just have to put your methods in a IPE structure to access the class from the DVR.
This is also the reason only property nodes work. Property nodes are supposed to be atomic actions, while methods could be blocking. That makes methods more likely to cause problems when invoked on a DVR. Especially when multiple methods are executed sequentially. So LV forces you to put those actions in a IPE structure...
But still...
A by value class can be put in a DRV to get a by reference class.
A by reference class will never be a by value class.
So if the class is intended to be reused and can be used by value, it makes sense to design it by value, and then either put it in a DVR or make a by reference wrapper. The other way around is not possible.
So if you have a by value class, and want to reuse it, you can either refactor it, or take it as it is and put it in a DVR or by reference wrapper.
That was what you where asking: why would you make a by value class and put in in a DVR...
@Loïc.W wrote:
I'm confused about what are the interests of using a DVR that's store an object instead of using a DVR as the private data of a class?
If I'm understanding well, with this method we lose the dynamic dispatch and cannot use directly the methods of the class... (But a property node works?! Wtf ?!)
I kind of like the idea, it's very easy to create a sub-class of the data that a Child use and reuse most all of the code.
I'm assume you're using a class with a (separate) data-class as it's only attribute in this case.
You'll have dynamic dispatch of the 'wrapper' class and a DVR to make sure you use the data data regardless of wire splitting.
I guess you can inherit the data class and have dynamic dispatch on that too.
I Think i'll need to test it out.
@Loïc.W wrote:Edit :
But still...
A by value class can be put in a DRV to get a by reference class.
A by reference class will never be a by value class.
So if the class is intended to be reused and can be used by value, it makes sense to design it by value, and then either put it in a DVR or make a by reference wrapper. The other way around is not possible.
So if you have a by value class, and want to reuse it, you can either refactor it, or take it as it is and put it in a DVR or by reference wrapper.
That was what you where asking: why would you make a by value class and put in in a DVR...
Yeah, I thought about it as the same time as I wrote my response.
But coding a class, knowing that I'll have to wrap it to be used through a DVR is not really satisfying...
If I really needed DVR functionality, I'd put the DVR in the class's private data.
If I have a by value class, I'd never put it in a DVR, because I'd use other mechanisms (events, queues, or... a wire). But that's OT.
This is not so much about style, it's more that DVRs came to the party pretty late. They where a means to an end, but LabVIEW developers didn't really design it to be used intensively. This is why debugging them is much harder. If you'd propose an idea to improve working with DVRs, I'm pretty sure the reply will be: "you're doing it wrong".
I started OO around the same time DVRs where introduced. I made a fair share of DVR classes. I refactored all DVRs out by now. The fact that when I stop my code, I can't debug anything because the references are gone spoils it for me. I think OpenGDS avoids this by allocating DVRs in a central broker, but I've moved back to by value...
@Yamaeda wrote:
@Loïc.W wrote:
I'm confused about what are the interests of using a DVR that's store an object instead of using a DVR as the private data of a class?
If I'm understanding well, with this method we lose the dynamic dispatch and cannot use directly the methods of the class... (But a property node works?! Wtf ?!)
I kind of like the idea, it's very easy to create a sub-class of the data that a Child use and reuse most all of the code.
I'm assume you're using a class with a (separate) data-class as it's only attribute in this case.
You'll have dynamic dispatch of the 'wrapper' class and a DVR to make sure you use the data data regardless of wire splitting.
I guess you can inherit the data class and have dynamic dispatch on that too.
I Think i'll need to test it out.
A DVR data class isn't enough. There would need to be a locking mechanism. If you 'get' the data from the DVR, modify it than 'set' it, you'll have a race condition. The IPES would lock it, but you can't split up the 'get' and 'set' in subVIs.
Perhaps I'd need to see your idea first.
I've found:
- It's easy to make a by reference class.
- It's easy to make a by value class.
- A class that does both* is near impossible.
* without significant amounts of duplicate code, wrapping everything, or data copies.
I've tried. I've asked others. It's hard with the tools we are given.
I did this in a ini file library. The parent is by wire, the child by reference. It involves reference counting, interlocking and data buffering.
I have an idea that would fix this all, but it would need additions to LabVIEW. And like I said, the reply will probably be "you're doing it wrong". That's the response I get a lot on the idea exchange.
There are classes that would be useful by value and by reference. For instance, a ini file reader. I'd like it by value, but it makes sense to have (an option to have it) it communicate over parallel loops. If only because the NI implementation does it like that.
Another example would be a current value table. I like it by value, but it would serve a purpose to make parallel loops communicate with each other.
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.
