Off the top of my head:
@JackDunaway wrote:
So consider this: it's tedious to create individual accessors for each data member - lots of clicking and lots of files to lug around with SCC. It would be so much nicer to be able to mark individually data members of the Class Data Cluster as "Public Read" or "Public Read/Write" or "Private". This would allow any caller of the class to use Bundle/Unbundle dropped directly on the object wire to access data - all class data doesn't necessarily need to be private! (again, this conversation must have happened before, please link if you know)
Once it's not a PITA to replace typedefs with classes, then I could begin to let go of typedef'd clusters for new designs.
I would love to see this point discuss in greater details - as it has come up before in local discussions, so I have no links.
Additional to this discussion, I have heard for example "It is painful to have to create Accessor methods just to access data in Inherited Classes..."
Obviously there is more overhead/work in using LVOOP but it is worth it.
Using scoped (private) data with subVIs provide data protection, which is one of the great benefits of LVOOP IMHO.
I think its goes against the principle of LVOOP to do what you are suggesting.
Off the top of my head: If you have public data as suggested, I can see that you would lose some benefit of encapsulation - what happens if I need to run some private methods before or after Data Member access? I.e. precheck data in range before exposing.
If this is required then I currently do this in the Accessor Method VI, so this is transparent to calling code.
So if in future something changes and I need to call a private method, and all I had simple bundle/unbundles in my code, I would have to troll through all my code and replace them with subVIs.
Which I could have avoided by using subVIs in the first place.
What about inheritance? E.g. This Accessor always does this to the data before exposing the data...
How would replacing/renaming/changing Data-Members cope?
If I break an Accessor can I quickly go into that subVI fix it (and elsewhere in my Class) and my calling code is protected?
Or am I stuck having to update every bundle/unbundle node in my code - just like I would a type-def?
In 2010, the PN kind of provides this feature - easy access but you need have Accessors created for it.
Maybe you could have a PN automatically available for Data Members when a new Data Member is created?
The developer could have the ability to create a custom Accessor Method VI if it was warranted in the future.
This would maintain a consistent API, that would stand up to changes and not break calling code.
I am very interested to hear other opinions on this.
Certified LabVIEW Architect * LabVIEW Champion
