Does anyone feel data accessed through property node similar as public data?

[mabolas]

Recently I use more and more LVOOP to build my project, the access data through property node helps me a lot.

I don't need back to project explore to find out where the data member access VI is.

(Sometimes it takes me lots of time if it's a big project , and most of time just annoying.....)

And I can easily access the parent data too.

 

One day suddenly I feel this action treat those data members really similar as the public data.

To be honest, I don't know any details in computer science opinion how NI made this and what's the

difference inside between public data and data access through property node.

As a user , I decide following the concept of duck typing

"it looks like public data, it acts like public data, and it's public data to me" 

 

And I wondering, have NI ever consider make LVOOP has the public data declaration like other language?(Like C++ or Java)

in the class , one is private data cluster, the other one is public data cluster, all the public data could be accessed through

property node , so that we don't need manually create data member access VI anymore.

When I select multiple member and create the data member access VI, tones of front/back panel pop out, I had manually save those VI one by one. It's a little bit inconvenient to me, especially when I build multiple classes and each class has multiple public data members.  

 

 

I know the NI white paper about LVOOP said they didn't decide let the class has public data yet.

But I really wish LVOOP has such declaration, it makes LVOOP much easy to use and much like other

traditional OOP language.

 

Dose anyone has similar idea as mine?

 

[ShaunR]

Whats the difference between your "public data member" and a global variable?

[mabolas]

the public data here I means the traditional OOP language declaration, could easily access outside

Like,

 

class Symbol
{
public:
char ID;
int Width;

int Height;

private:
int pd;
};

 

the public data here means "ID,Width and Height"

[hooovahh]

I sorta agree.  I mean on the surface I wonder why do I need a VI for every read/write property?  Why can't I just specify what data is public, and if that data is read only, write only, or both.  Then have the property node work without needing to write a tons of VIs, even if the majority of it is done through scripting and templates.

 

But having a VI for these actions does add other flexibility.  Like if I perform a write I can have that VI do more than just set some data, it can also manipulate the data or perform some other action other than just a bundle by name.

 

That does make we wonder why NI choose to do what they did, and allow public data accessed through a property node, via a VI call.

[mabolas]

I sorta agree.  I mean on the surface I wonder why do I need a VI for every read/write property?  Why can't I just specify what data is public, and if that data is read only, write only, or both.  Then have the property node work without needing to write a tons of VIs, even if the majority of it is done through scripting and templates.

 

But having a VI for these actions does add other flexibility.  Like if I perform a write I can have that VI do more than just set some data, it can also manipulate the data or perform some other action other than just a bundle by name.

 

That does make we wonder why NI choose to do what they did, and allow public data accessed through a property node, via a VI call.

 

Sometimes I do manipulate data members via data access VIs, but only in static dispatch VI.

And I didn't mean erase this specific method from LVOOP, I just hope LVOOP could provide another way more easily to set up public data members.

It also makes LVOOP has similar property as other OO language.

I think it will help LV programmers to communicate other OO language programmers.

[drjdpowell]

I suspect there might be a concern that making “public†data members easier would discourage more careful design.  There are reasons why heavy use of “properties†might be thought of as a “code smellâ€.  Of course, a significant fraction of the time one really does just need a direct read/write access to a data member, and a “public†declaration would certainly be convenient.