Access Class Data with Property Node - Easier Way!

[SteveChandler]

You can access the data in your class using property nodes.

Currently all you have to do is select "Make available through Property Nodes" when creating your accessor. I think it would be cleaner if there were simply an Access Scope setting on the control like so:

The idea here is that there is no VI behind the scenes. If you later decide that you want to keep the data private, all you have to do is change the setting. You don't have to remember to delete the VI.

I am guessing that the majority of class VIs are simple accessors. This idea will reduce the number of files to create and lug around increasing edit time performance and would make your class libraries load faster.

Many people (myself included) do not prefer property node access because they can be big and clunky. A possible enhancement to this idea is to put a "Universal Accessor" in the Cluster, Class & Variant palette that looks and acts like a polymorphic VI.

[Edit: the polymorphic selectors in the above image should just say 'Numeric' instead of 'Read Numeric' and 'Write Numeric' as that is implied]

[Intaris]

Hmm.  I tend to have some code associated with my accessor VIs in order to maintain a clean otuward interface even if for efficiency reasons the internal representation changes.

This wouldn't be possible here so my question would be:  How would we override these accessors?  If a Child actually DOES declare an accessor VI and the parent has a public private data field, which is used and how is the decision made?

Shane.

[SteveChandler]

I would define a simple accessor as nothing but a bundle for write or unbundle for read. Once you have any other code in it then it becomes a method. This is my definition and it may be wrong from a computer science perspective. But lets define it that way for the purposes of this idea. If you want to add any code then you would not be able to use this "VI-less accessor".

You bring up a good point about dynamic dispatch. I don't know how that would work since it is specified with the terminal of the VI. I guess that is what the comments are for. Anyone know how this should work? I am thinking something like once you create a VI accessor then things automagically work the way they do now.

[dthor]

I like the "Universal Accessor" that you mentioned. A polymorphic VI that automatically morphs to whatever items are in the class seems pretty dang cool to me. It would definitely mean that I have fewer subVIs to make. I'd say only about half of my class methods have more than "Unbundle" in them. Also, the Universal Read accessor should have a default value input that activates on Error.

As for the implications of it, such as the previously mentioned override and dynamic dispatch, I've no idea how those would be effected or if they would cause this Idea to be impossible. I'll let someone else decide that. 

[Intaris]

You can define an accessor whatever way you want but in LV, there is no real distinction made between accessors and methods except that one gets to be a property node and the other one doesn't.  A VI set as a data accessor (tghus available via Property node) does not allow bidirectional data transfer.  It's either input or output, not both.  This limits the scope fo such "methods".

I like using certain logic in my accessors because IMHO that's where certain code belongs such as range checking for specific classes or transformation of data from a public interface to match an internal representation (i.e. when my "accessor" doesn't actually have a corresponding 1:1 control in the class private data).

[SteveChandler]

I understand what you are saying about putting code in your accessors. I do it all the time for things like input verification. Obviously if you need code in your accessor then you could not use this because you need a VI to put it in. As I said, this would be limited to use as a simple accessor with only a bundle for write or unbundle for read. Anything else and you cannot use it. Most of my class methods are what you get when you select create accessor. The only thing I do is put some text in the icon.

[David_Staab]

Steve, it seems like what you're ultimately asking for is that the "bundle" and "unbundle" nodes be made to work for appropriately scoped data members, instead of breaking the wire for every non-member VI. I could get behind that implementation.

[SteveChandler]

Allowing bundle/unbundle on scoped data members was my original idea but I kept it to myself while I thought about it. There was something that I just didn't like about it. I then realized that it is because I really don't like the way those look. I prefer how the property nodes look because the class wire stays at the top and it has error in/out.

[StephenB]

I went back and forth on this but I think I agree with it.

Class data should be private by default and exposed by accessors. This is recommended practice in all programming languages because clients aren't broken if the class designer needs to add in code to the accessors beyond simple get/set. Or if another class needs to override the accessor. If data is exposed with accessors, all of this is transparent to the client.

SO if this was implemented... and clients must access the data with a property node... this idea works out. Because the class designer could implement an accessor (available as property) with the same name and clients would not be broken.

The only thing I don't like about this is the inability to act on the data inplace. If data is only ever accessed via property nodes (which it should be!)... you can't use the in place element structure. I think this is a general short coming of LabVIEW at the moment though which is outside of the scope of this idea.

[Intaris]

I'm kind of with StephenB in that I'm unsure about the impact of this idea.  I truly understand the wish to have convenient definition of access to class data, but I'm not sure this is the best way.

Making this data public is essentially un-ooping the data.  Why not simply allow a bundle and unbundle of those elements which are declared public ont he BD of ANY VI?  Would that not be the easist solution?

Just to be clear, I'm not proposing this as a good idea, I just want to have different approaches discussed before something like this might get implemented.  I love OOP and I agree 100% with the sentiment behind the idea, I'm just unsure about the details.

Shane.

[fabric]

Did you see this related idea? Unfortunately it never really got off the ground... I think Jack's matrix freaked people out! 🙂

I like the essence of both these ideas: That creating plain-vanilla accessors is a pain that we could surely do without.

I agree that sometimes the accessor needs more code, but 90% of my accessors don't need any extra code. In those cases I would love an alternative implementation that doesn't require a file on disk, a custom icon, etc...

I'd still like to see a better implementation for how to achieve this. IMO a right-click option for each data member hides too much. A possible alternative might be to provide additional cluster containers alongside "Cluster of class private data" for Community, Protected, Public... That would at least be more explicit!

Anyway, kudos for the general concept, but refinement of the idea still preferred...