OOP Interfaces, automate data accessor code

[mjhakkar]

Interfaces are a great improvement in LabVIEW OOP. For me steepest learning curve was in figuring out how to implement default behavior when interface class doesn't have a private data control.
For example I have created Collectable interface (inspired by iterable interface found in other languages). It has default implementation for methods like Next and Add. It has accessors methods like Read and Write Items, which descendants must override.
When I create a new class which inherits from my Collectable interface, I need to override those accessors, and manually add required controls to new class private data control, and unbundle/bundle elements, and wire the controls and indicators.

data accessors

My idea is that there should be a tool to do automate this code generation.

I think the straight forward way would be to use scripting and project providers to create something similar to Actor Framework Create message etc. tools. 
But a more fundamental change would be to implement this as part of property definition folders and property nodes. Which I think in this case should be in protected scope by default.

property nodes

The Collectable interface can be found from lavag.org 

[JimB.]

This (mostly) already exists. Just right-click on your class in the Project Explorer, and select Add>VI for Data Member Access...

That will automatically create accessors for your private data members. If you create them as dynamic accessors and give them the right name, then they will fulfill the contract set by the interface. (If you stick the Read/Write naming convention and name your label your private data controls as expected, the automatically generated accessors will even have the right file name.)

The only part this doesn't do is automate adding the data members to the private data cluster, but I don't think it should for a couple reasons:

• Interfaces do not have data accessors because they do not have data. While you can define properties on an interface, it seems bad practice to me to force those properties to be implemented as private data in inheriting classes. Related to my next point...
• An interface should not make assumptions about the classes that implement it. What if the array in my class isn't named Items? What if I have an array called Items, but it isn't the one I actually want to return as Collectable.Items?