Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/28/2023 in all areas

  1. When I did my first big LabVIEW OOP project (from scratch) a few years back I went "all in" with creating accessor nodes. Maybe it works better in other programming languages but in LabVIEW all those read write vi's clutters up. There are a few cases where it could be useful, like if you have a underlying property of the class (like time) and you want to read it in different formats (timestamp, string, double) making an accessor vi with small modifing code can be quite neat. Also I work with a real time application and since each accessor is a vi I'm not sure of it affects preformance. Extra settings like reentrancy needs to be taken into account I guess. So now when I'm trying to identify preformance issues I replace any accessor node possible with bundle/unbundle just to be safe. Fully agrees with @Neil Pate. Nowadays I'm much more restrictive.
    1 point
  2. +1 for Unbundle. It it simple, requires less code and you understand immediately that these elements belong to the current class. They are also easier to maintain in case you ever feel the need to change the name or type of an element and work well with In-Place Element Structures in Unbundle-Bundle-Scenarios.
    1 point
  3. I exclusively use the bundle/unbundle, unless I am not able to for example if accessing a field in a parent class. Accessors should be, in my opinion, only for when you want to get access to the data from outside the class, and even then you should really think about if this is strictly necessary. Often you can get rid of accessors by having a better designed API (methods). Lots of sets/gets is a code smell to me.
    1 point
×
×
  • Create New...

Important Information

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