LabVIEW
Functional global with too many terminals
@Bublina wrote:
Isnt this exactly what LVOOP is usefull for ?
If I made the FG in LVOOP style, I would still keep data in prison and get the possibility to select the method (function) and get different terminals for each class member.
Exactly, the differences between a "LVOOP" Class and a FGV "wrapped up to nirvana" are fairly small when it comes down to actually running.
There are some small perfomace penalties with either approach but you hardly ever NEED highly optomized code to expose data storage retrival and manipulation functions. (You need to be smart about data copies but, an extra synchronization boundry here and there is not an issue) What choice you use should depend on your audience. Can your client understand the code? for some reason I can't really define most users of LabVIEW don't understand OOP and IT SCARES THEM!
Maybe the next generation of bright minds will be taught a OOP class in kindergarten.
@JÞB wrote:
@Bublina wrote:
Isnt this exactly what LVOOP is usefull for ?
If I made the FG in LVOOP style, I would still keep data in prison and get the possibility to select the method (function) and get different terminals for each class member.
Exactly, the differences between a "LVOOP" Class and a FGV "wrapped up to nirvana" are fairly small when it comes down to actually running.
There are some small perfomace penalties with either approach but you hardly ever NEED highly optomized code to expose data storage retrival and manipulation functions. (You need to be smart about data copies but, an extra synchronization boundry here and there is not an issue) What choice you use should depend on your audience. Can your client understand the code? for some reason I can't really define most users of LabVIEW don't understand OOP and IT SCARES THEM!
The only reason why am I not doing any commercial stuff using LVOOP is that I have never done any commercial stuff using LVOOP 🙂
There is allways a darkzone factor for big projects (something is not working sometime and you have no clue why) and you have to find it out the hard way. So I hardly ever use new features if I am not forced to.
I am familiar with OOP, I had to learn Cpp and C#, but it was not easy to start with LVOOP. No wonder, that folks with no OOP knowledge fear it.
@for(imstuck) wrote:
@Bublina wrote:The only reason why am I not doing any commercial stuff using LVOOP is that I have never done any commercial stuff using LVOOP 🙂
There is allways a darkzone factor for big projects (something is not working sometime and you have no clue why) and you have to find it out the hard way. So I hardly ever use new features if I am not forced to.
I am familiar with OOP, I had to learn Cpp and C#, but it was not easy to start with LVOOP. No wonder, that folks with no OOP knowledge fear it.
My 0.02 with regards to this, as I have relatively recently started messing with OO (6 months or so). There is no rush to dive into OO, so don't rush yourself. I waited until I got some small projects to start with. I didn't just decide one day that I had a 1,000 hour fixed price project that I was going to "learn OO" on.
You will be compelled to "get great flexibility and code reuse" from OO. I would suggest not falling into this trap. When you start trying to use dynamic dispatch for everything so you can just "plug in other modules" it becomes overkill when you don't need it and you cause a big pain for yourself (and potentially others).
The wise, LabVIEW Champion Ben Rayner told me over a Texas steak and a beer that doing a project with OO doesn't mean the entire thing needs to be OO. There is nothing that says your file handling can't be OO without everything being OO. If something makes sense to use OO, then use it. If you can't think of a good way to use OO for another part because you're learning, then don't.
I'l leave you with some food for thought from a g chat I had with another LabVIEW Champion, Jack Dunaway, while I was starting to use OO more extensively: "yeah; the trick, is not leaving a wake of destruction with colleagues who don't necessarily believe in LVOOP. it's tricky; be careful."
Oh look at you Greg. Quite the name dropper.
(Just giving you a hard time)
In regards to the thread I would recommend using LVOOP. While there can be a steeper learning curve OOP does bring quite a bit to the table and can make code reuse much easier. I also believe that your code will be much more readable using a LVOOP approach over a super bloated action engine. As you already learned managing your connector pane is becoming very difficult. Also, the documentation for individual methods will be much easier than trying to document all of the actions available in your action engine. If you have 20 fairly complex actions the documentation for that single VI will read like a book. Whereas individual methods will only require the documentation for the single task being performed by the method. You can also leverage dynamic dispatch.
@Mark_Yedinak wrote:
Oh look at you Greg. Quite the name dropper.
(Just giving you a hard time)
Debated long and hard about the name drops, actually. But, I decided they help to improve credibility.
Oh, the wise LabVIEW Champion Mark Yedinak once called me a name dropper, and then I made him buy me a beer at NI week.
for(imstuck) wrote:Oh, the wise LabVIEW Champion Mark Yedinak once called me a name dropper, and then I made him buy me a beer at NI week.
In a way, you already bought him dinner at the CLA Summit this year (mine as well). Ok, it was your company. But still. I guess that means you should have two beers coming your way.
