09-24-2011 09:03 PM
A brief justification for the need of By Reference classes followed by a survey of techniques implemented over the years to acheive objects-by-reference functionality, and a host of things to consider.
Here's some related Idea Exchange entries:
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LVClass-By-Reference-Features/idi-p/1673950
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Class-constructors/idc-p/1728714#M14753
-Nate Moehring
9/24/2011
09-25-2011 02:54 PM
04-12-2012 10:41 AM
Quite a nice description of definitions, capacities, and options for implementation of by reference objects. Thanks Nate!
11-19-2014 06:03 PM
I'm a huge fan of #5 Private DVR / Protected Data -- it's the biggest bang for the buck with the fewest drawbacks/cons.
11-20-2014 09:42 AM
11-20-2014 12:33 PM
Hi Nate. We should defitely chat more about this. Over the years I've created (and collaborated on) several by ref frameworks (and I've certainly used GDS) -- I was originally inspired by the Endevo GOOP toolkit. At JKI, we've got some in house tools that I'm hoping to open up more (to the community) in the future. I'd love your input on this topic -- it's near and dear to me.
FYI, there's an appendix in LabVIEW for Everyone 3rd Edition that talks about the evolution of by ref OOP (prior to LVOOP) -- I added this, since LVOOP was supposed to be released around the time of the book, but LVOOP got delayed and I was inspired to include a taste of OOP in the book. I based this chapter on my work implementing OpenG OpenGOOP (semaphored reentrant LV2G's called by reference and some of the SciWare GOOP Developer templates.
Tomi Maila and I worked together on more sophisticated OpenG Object templates that support nested locks. At JKI, we developed a sophisticated (and somewhat bloated) active object framework (think By Ref Objects + JKI State Machines + GUIs + Public/Private Events). Lately, we've been working to decompose these into tools/templates that are more lightweight and composable.
I've played a bit with Actor Framework, but it tends to solve problems I don't really have (I've never really been a fan of the Enum+Variant based Queued Message Handler architectures, due to the difficulty in visualizing and debugging the program flow) and create new problems I didn't have before. I much prefer the ease of development and debugging of the JKI State Machine and then adding support around it for by reference OOP and life-cycle management. However, I'm thinking that Actors could be a nice way to implement some of the communication between class methods and their asynchronous process(es).
Hmmm. I should probably add some more info the History of GOOP on the LabVIEW Wiki
11-20-2014 12:34 PM
I'll also add that I loved reading your "Using Objects By Reference" doc, Nate. Very good stuff! Kudos.