LV OOP when using accessor methods (subVIs) or bundle/unbundle operation?

[MichaelMachate]

Hello

When should I use the (private) accessor methods (subVIs) and when the bundle/unbundle operation to access the class data? What is the reason that the bundle/unbundle operation is introduced to LabVIEW OOP? I need some rules for a coding guideline.

Thanks

[Norbert_B]

Hm, this sounds rather simple:

The data is not accessible outside of the class using bundle/unbundle. So when you are trying to access data from an object outside the class itself, you have to use accessor methods (class VIs, which usually simply use bundle/unbundle for the class data).

But maybe i misunderstood your request and it is not as simple.....

hope this helps,
Norbert

[MichaelMachate · Accepted solution]

Thanks for your hints. I wanted to understand the differences between a private vi access and the unbundle operation like in the picture.

I found some more explanations on the website: http://www.ni.com/white-paper/3574/en

-> "Creating "read" and "write" methods for every data value in a class is a process acknowledged to be cumbersome. LabVIEW 8.5 introduced the ability to create accessor VIs from a wizard dialog, and LV2009 added further options to that dialog.

We were concerned about the performance overhead of making a subVI call instead of just unbundling the data. We found that our current compiler overhead for the subVI call is negligible (measured between 6 and 10 microseconds on average PC). A bundle/unbundle operation directly on the caller VI versus in a subVI is nearly the same amount of time. We do have an issue with data copies for unbundled elements because much of LabVIEW's inplaceness algorithm does not operate across subVI boundaries. As a workaround, you may also choose to avoid accessor methods in favor of methods that actually do the work in the subVI to avoid returning elements from the subVI, thus avoiding data copies. This choice is frequently better OO design anyway as it avoids exposing a class' private implementation as part of its public API. In future versions, we expect that inlining of subVIs will become possible, which will remove the overhead entirely.  

We feel in the long term it is better to improve the editor experience and the compiler efficiency for these VIs rather than introducing public/protected/community data."