Jump to content

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


Recommended Posts

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?

 

Link to comment

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.

Link to comment

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.

Link to comment

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.  

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.