Using Objects By Reference 111013.pdf

[Nate_Moehring]

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/Have-Dynamic-Dispatching-terminals-accept-Data-Value-r...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Class-constructors/idc-p/1728714#M14753

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Implement-STL-like-standard-containers-Data-Structures...

-Nate Moehring

9/24/2011

[Nate_Moehring]

Please feel free to submit comments regarding the accuracy and completeness of this presentation.

[Jeremy_Marquis]

Quite a nice description of definitions, capacities, and options for implementation of by reference objects.  Thanks Nate!

[Jim_Kring]

I'm a huge fan of #5 Private DVR / Protected Data -- it's the biggest bang for the buck with the fewest drawbacks/cons.

[Nate_Moehring]

Thanks Jim.  Do you do this style of programming exclusively with GDS, manually, or home grown tools?

[Jim_Kring]

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

[Jim_Kring]

I'll also add that I loved reading your "Using Objects By Reference" doc, Nate.  Very good stuff! Kudos.