Selectable Class Data Member Scope

[JackDunaway]

Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.

Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.

I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:

1. Obviates all the piddly accessors clogging your project tree and SCC server
2. Allows quick visual recognition that a data member is being read/written directly (no data transformations were snuck into the accessor)
3. Cleaner interface for callers of the class using the Bundle/Unbundle
4. Best of all, saves considerable development and maintenance cost

Here's an example of what the Data Member Scope Configuration screen might look like:

Note that clusters can have "Custom" scope, which means the cluster's elements have different scopes. Also note that when a cluster's scope is set explicitly, it's members inherit the same scope and cannot be set (note how 'x' and 'y' are greyed under 'Center of Mass'). The default behavior (which is equivalent to today's default scope) is for 'Class Data Cluster' to be 'Private' with all descendants greyed.

This Idea is one product of a discussion which has taken several routes.

[Jolt]

I get that it might be hard to do and there could be issues with migration when the parent changes or an "overriding" accessor is created.

However, the "brittle" argument in previous post seems like either a stretch or overly-cautions. How is this that dissimilar to any type-defined cluster referenced in various sub-vi's that changes? LV does a decent job of helping a developer find and fix things that are potentially screwed up when a typedef changes (imperfect but not bad!).

For myself I find it incredibility cumbersome to create accessors for every parent data element the child needs to use. To me, access to the data defined by the parent is a big reason I create a common ancestor in the first place!

For that mater, my mutli-click-and-then-formated-saved-etc. accessors can break along with anything using them when data definitions change. And if it was a generic accessor in the first place, there is little chance I can put some magic code in the accessor to satisfy all callers. So the point here is that again, if something changes things break and they need to be fixed here, there, and everywhere anyway. Why not have easier access in the first place and at least same some time and resources on the front end. 

To be clear I'm advocating parent data to be in protected scope accessable by children via un-bundle (or baring that, fancy auto-available property node fields).