I'm starting the process of transitioning 3 large applications into one using LVOOP. After getting used to NI's terminology for it (why does everything need to be different from the standard vocabulary with NI?), I've got most of the groundwork laid for the real implementation to begin. Before I venture down this road for real, I'd like to hear the opinions of the seasoned LV devs on the capabilities and caveats to using LVOOP. A couple of the big posters on this forum admit to not even really using it, so I'm starting to question if it's a mature enough technology to handle what I'm about to throw at it.
I use it in almost all of my applications anymore. Rarely do I regret it. The only thing you have to remember is that LabVIEW's objects are value based, not reference based. That seems to cause people coming from a C++ background to slip up. Otherwise, I find it fairly straight forward. A lot of bugs have been worked out since OOP came out in LabVIEW 8.2. I would say it is definately mature enough to work with.
I don't do much development myself but the theme of this years CLA Summit was building better LabVIEW applications and it was basically all OOP. The community group linked below might also have some other input.
Was there something in particular that you were concerned about LabVIEW OOP not doing well or were you just looking for general input from others?
My biggest fear is deploying the new version of the application, and six months down the line getting a call with cryptic "ClassNotFoundException" type errors from a client. The codebase as it stands is pretty foolproof to use, but expansion is getting difficult without proper OOP.
In short, yes, but it's value based OOP as already mentioned.
If you want to use reference based OOP, take a look at out G#, it's basically LVOOP with DVRs (and garbage collection and some other C# features).
Yeah I've seen that from the whitepaper. Nothing I plan on doing is really all that fast or limited in resources, so that doesn't bother me all that much. Thanks for the input. I'm going to keep this thread open for more input before accepting any "solution".
Well, I don't know how you would pick a "solution". Just about everyone who has been doing serious, high-level, big-project LabVIEW development over the past, say, 5 years has gradually drifted towards LVOOP. Does that make it "mature enough for large applications"? Well, that's a matter of opinion. If the Developer(s) are "mature" and "experienced" enough to understand how to use LVOOP and are comfortable with it, it certainly seems to be "the way to go". So the key question, it seems to me, is "Does Our Development Team (which may be a Team of One) Understand LVOOP to Commit to Using It?".
P.S. -- I'm an example of the "Team of One" who wants to go to LVOOP but is not yet quite ready to "make the leap" ...
... OOP is very good at providing things like hardware abstraction layers and the like. It is very poor as an overall structure for an application. I have seen many applications that were built 100% on OOP. I have not however seen any good ones -- where good is defined as readable, maintained and extensible...
Play angelic chorus.
. I have seen many applications that were built 100% on OOP. I have not however seen any good ones -- where good is defined as readable, maintained and extensible. Even C++ is widely criticized as a "write-only" language....
Gee thanks Mike!
Just becuase it ws my first totally LVOOP project and it was written in LV 8.2 and DVR's and worker pools had not been invented yet and it had to allow editing the Front Panel while the application was running and had to support adding new Front Panel controls to an executable...
What did you expect?