LabVOOP Usage 1 Year Later

[Aristos Queue]

If you have comments about the *overall* nature of LabVIEW classes, please post them here. Please don't post feature requests here. I'm interested mostly in getting a feel for adoption rates. I'd like to know how secure everyone feels doing professional development with LabVIEW classes. If there is a particular sticking point (other than you haven't upgraded at all yet) that is keeping you from developing with classes, I'd be interested in that.

[Jim Kring]

QUOTE(Aristos Queue @ Aug 22 2007, 04:16 PM)

If you have comments about the *overall* nature of LabVIEW classes, please post them here. Please don't post feature requests here. I'm interested mostly in getting a feel for adoption rates. I'd like to know how secure everyone feels doing professional development with LabVIEW classes. If there is a particular sticking point (other than you haven't upgraded at all yet) that is keeping you from developing with classes, I'd be interested in that.

I've jumped in head-first, but only recently. Several "planets" have aligned:

• The Endevo GDS makes editing classes so much easier and I'm happy to have access to by-reference classes in the project.
  
• The OpenG Class Templates for Object Oriented Programming give me the assurance that I can tweak the by-ref templates.
  
• LabVIEW 8.5 promises more features and better stability :-)
  

I'm bugged by the fact that building EXE's requires so many hurdles (segregating class hierarchies due to dynamic dispatch VI name collisions. I'm in the middle of building an EXE out of my big app with lvclasses, right now (pulling what little hair I have left out).

I'll have more to say in coming months, once I can spend more time in 8.5...

Thanks for your tireless effort on LVOOP. It's really great and going places

[PJM_labview]

I played with it, but I don't have a major project involving class.

One of the reason is that the entire class is broken when one member VI is broken.

AQ, while you tried to explain the reason for it in another LAVA post, this was a huge turn off for me (debugging nightmare--> spend an entire weekend wasting time around this. And yes I know about the red cross next to the culprit VI). This coupled with lvlib relinking "pain in the behind" lead me to conclude, at the time, that the LabVOOP was not useable (I have not revisit this since).

Also, I have to say that after reading about all the issues that TOMI encountered, I was not too motivated to spend more time to get into it.

Eventually I am sure I will end up using it since I am using other by ref GOOP flavor.

PJM

[Grampa_of_Oliva_n_Eden]

I have not used it because I just did not get it.

I have started reading on OO and it sure looks a lot like what I do every day. It looks like it is just a vocabulary thing with me. It is starting to click. I hope to implement LabVOOP in some experiments before trying it in a real app.

Ben

[Justin Goeres]

As I mentioned at NIWeek, I use it in every one of my projects now. There are a few reasons for this:

• I forced myself to start doing that a few months ago and "got used" to it.
  
• I have not found the time to use/purchase any of the by-ref GOOP stuff in 8.2 or later, so LVOOP is my best option for object behavior.
  
• I desperately want to believe that AQ and the rest of the LabVIEW team were onto something (as opposed to simply on something) when they created it.
  
• I really like the way I organize my code when I use it.
  

I completely agree with Jim's and PJM's sentiments, but those are things that I've either learned to live with or have structured my workflow around.

That's not to say there aren't drawbacks. My ImageMagick library, for instance, throws errors if I try to build it into an application. I can't for the life of me figure out why, or how to fix it, and for now I've given up. If I had a library that large for a customer project and it did that, I would throw my laptop through the window . The solution has been to do frequent interim builds of all my software in the hopes of at least catching whatever disease the library caught. (Note that this is a good behavior to have learned anyway )

Likewise with the "whole class breaks on one broken VI" thing. I live with that, kind of like how we all learned long ago to live with the concept of the Run arrow breaking on any error in the associated VI hierarchy. It requires slightly more attention to detail than I'd like sometimes, and some judicious use of the Diagram Disable at other times, but I get by.

1 Thing I Hate About LVOOP: Not being able to have name collisions among unrelated class members in built apps (unless this changed in LV85? I haven't checked.). If I can have two VIs in two different (unrelated) classes both called "Set Value" (or something equally ubiquitous) in the Development Environment, I should damb well be able to build an app out of them. Honestly, if I'd known about that lovable little feature before I started using LVOOP, I might not have started. And then you wouldn't have me as such a big LVOOP fan . It's a game of inches, I tell ya.

[jaegen]

Here's the thought process I went through when I first saw the release of 8.2:

1. Native classes in LabVIEW??!! With inheritance??!! Woo hoo!!!

2. By-value only??!! Nooooooo!!!

3. (a few months later) Hey, this by-value stuff isn't so bad ...

4. (a few more months later) Hmmmm, this by-value stuff actually makes complete sense

5. (a few weeks ago) Recursion??!! Woo hoo!!! (Disclaimer: This happened to come along at exactly the right time for me - I need a tree class)

I hadn't heard about the built-app-name-collision thing until just now (I haven't tried this yet - is it there in 8.5???), and the whole-class-breaks-if-one-VI-is-broken thing just sort of made sense to me when I discovered it, so I've worked around it. Like Justin, I love how code looks when it uses classes well, and I'm very much looking forward to seeing the end result of classifying(?) ... objectifying(?) ... my big application.

Jaegen

[eaolson]

QUOTE(Aristos Queue @ Aug 22 2007, 06:16 PM)

If there is a particular sticking point (other than you haven't upgraded at all yet) that is keeping you from developing with classes, I'd be interested in that.

I'm currently playing around with objects in a project I'm doing for fun, mostly so I can learn how they work. I was very frustrated at the beginning trying to find information on exactly how LabVIEW classes worked. There are a few pages in the online help, but they're not particularly well organized. For example, I'm still not entirely clear on how an Override VI is different from a dynamic dispatch VI because nowhere in the help is an Override VI defined. I'm also a bit muddy on dynamic dispatch VIs themselves. Like, if I have a heirarchy A -> B -> C, and I want to create a dynamic VI for A and C, do I have to create one for B as well? How does Call Parent Method work in that case? How do classes, projects, and project libraries overlap and work together? Am I supposed to be putting my classes inside libraries inside projects? (Project libraries bug me too, but that's for a different day.)

[jaegen]

UPDATE:

(Note: I never tried this in 8.2, so I have no idea whether 8.5 is different)

I just built a little EXE with 2 classes, both with member VIs named "Read Value.vi" and "Write Value.vi". The builder won't let the VIs co-exist inside the *.exe file, so it automatically adds folders below the *.exe's folder and puts the VIs there. To manually control this, you can create custom destinations within the build spec, or set VIs to be renamed in the build. There may be other ways. The same thing happens whether one class is a child of the other, or they are just peers.

I can certainly see this being a problem with dynamic calls and such ...

Jaegen

[i2dx]

my answers are:

I have tried it, but I do not use it in major appications and I am waiting for by reference objects.

my reasons:

first, I am stuck with the c++ object model: I create a class and use instances of them in my code. LVOOP does not fit in my "what objects are and how to use them" - world

second: I have lots of work and I am allways short on time, so I take the risk of using a new feature and maybe needing extra time for learning only if I am sure, that new feature will save me time later. I do not believe, that LVOOP at the current stage can speed up my development.

third: I am used to the heavy usage of old style / functional globals. The big advantage (in my eyes) is, that all data of that "module" are stored inside that VI and I don't have to drag the wires across my application (except the error cluster). As far as I experienced LVOOP classes do not automatically store their members and I have to drag lots of wires again.

[Jeffrey Habets]

I've been doing OO development in LV for several years now with Endevo's GOOP2.

I was very excited when I first heard of LVOOP coming to LV and toyed with it as soon as I got my hands on it. But it never went further than that..

Reasons for me to not use them where:

• Lack of proper tooling, I was actually used to saving time doing OO, not spending more.. :-)
  
• Problems with build exe's, this is a HUGE problem since most of my customers require exe's. I was hoping this would be fixed in 8.5 but Jaegen's reply didn't sound to hopefull.
  
• I need by-ref, I simply can't implement my oo-designs with just by-value classes.
  
• I don't do an awfull lot of LVRT projects, but if I do I would like to use OO there too.
  

Now most of these issues are taken care of by Endevo's GDS and one of the by-ref wrapper frameworks it supports, so it is highly likely I wil be using LV-classes next year.. :thumbup:

But this all depends on the behaviour of classes in executables.. I hope to have time to do some internall testing so I can use it with confidence in a customer project.

[gmart]

In LabVIEW 8.2, there were issues with trying to build applications that used LabVIEW Classes. The root problem in this particular scenario is that when excutables are built, the files are stored in one location so you can't have two files of the same name. So for name collisions, the mechanism app builder uses is save the files with name collisions outside of the executable in their own folders. This is the same mechanism used for name collisions within Libraries. With Classes, though, there was a bug that the names of the files would be changed. So overrides would not work since the names didn't match. The workaround would be to make each class go to a custom destination. This bypasses the automatic redirection that the app builder uses.

The above problem was corrected in LabVIEW 8.5. You will still get a hierarchy outside of the executable but the names will not be changed. In addition to this issue, other bugs with building apps with Classes have been corrected. Building apps with Classes has been greatly improved in LabVIEW 8.5.

[jaegen]

QUOTE(gmart @ Aug 23 2007, 06:03 AM)

...

The above problem was corrected in LabVIEW 8.5. You will still get a hierarchy outside of the executable but the names will not be changed. In addition to this issue, other bugs with building apps with Classes have been corrected. Building apps with Classes has been greatly improved in LabVIEW 8.5.

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' target="_blank">security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.

Jaegen

[Jim Kring]

QUOTE(jaegen @ Aug 23 2007, 08:50 AM)

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' target="_blank">security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.

Jaegen

Actually, it is still possible to unbuild a LabVIEW executable app into its constituent files. When building an app with LVClass's that causes the VIs to be outside the executable, the VIs will still (by default) have thier Block Diagram's removed (which is not quite "out in the wild"). It just waives it in our faces that built LabVIEW applications are by no means monolithic.

[gmart]

QUOTE(jaegen @ Aug 23 2007, 10:50 AM)

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "http://thinkinging.com/2007/08/19/password-protecting-vis-is-security-through-obscurity/' target="_blank">security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.

Jaegen

We are looking at ways to not have to place code outside of executables. For those who use the Mac (and you know who you are), built apps are one "file". The reason is that on the Mac, apps are folder-ish. So send your thanks to Steve Jobs on that one.

[Michael Aivaliotis]

QUOTE(jaegen @ Aug 23 2007, 08:50 AM)

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system).

I agree with jaegen on this one. Single EXE build needs to be a future feature. This restriction alone will turn off many from adopting Classes. Let's not forget that people (including myself) have been building successful test systems for 20 years before classes were introduced. Even without classes, work can still go on as usual - until NI forces us to use classes (which they probably will). I'm in favor of classes, I'm using classes in customer projects, but the more gotchas you present, the harder it is to convince people.

[i2dx]

QUOTE(Michael_Aivaliotis @ Aug 23 2007, 07:10 PM)

Even without classes, work can still go on as usual - until NI forces us to use classes (which they probably will). I'm in favor of classes, I'm using classes in customer projects, but the more gotchas you present, the harder it is to convince people.

I hope nobody will force me to use classes. Nobody forces a C Programmer to switch to C++! And IMHO it's a bad idea to force a programmer to use a specific feature. If that feature gives him an advantage (faster, better, cleaner code, etc ..) he will use it. That would be the only "force" I'd accept.

Besides:

I consider the first LVOOP features as a stepstone to a new programming language (maybe called G++ ?) which needs - accoording to the statement of Dr. T - at least 15 years for widespread addoption

[Grampa_of_Oliva_n_Eden]

QUOTE(i2dx @ Aug 23 2007, 01:35 PM)

I hope nobody will force me to use classes. Nobody forces a C Programmer to switch to C++! And IMHO it's a bad idea to force a programmer to use a specific feature. If that feature gives him an advantage (faster, better, cleaner code, etc ..) he will use it. That would be the only "force" I'd accept.

Besides:

I consider the first LVOOP features as a stepstone to a new programming language (maybe called G++ ?) which needs - accoording to the statement of Dr. T - at least 15 years for widespread addoption

That may be just enough time for me to complete the paradym shift.

Ben

[Jim Kring]

QUOTE(gmart @ Aug 23 2007, 09:15 AM)

We are looking at ways to not have to place code outside of executables. For those who use the Mac (and you know who you are), built apps are one "file". The reason is that on the Mac, apps are folder-ish. So send your thanks to Steve Jobs on that one.

That's very cool. However, it provides only convenience for app users, but not security for app developers.

It seems that it should be technically possible for NI to define a virtual subdirectory scheme inside of LLBs. This is possible, already for ZIP, TAR, and other archive schemes. Then the class members could be segregated into virtual folders inside the EXE (which is really just a special LLB) file.

[Tomi Maila]

I've been using LVOOP for one whole year now. At the moment all my new projects use LVOOP and I've encapsulated some old libraries to LVOOP as well. With LV 8.20 there were a huge number of issues and the first half year was a nightmare, although an expected nightmare After 8.2.1 was released the life with LVOOP became a lot easier as LVOOP projects became a lot more stable.

LVOOP has enormously helped in the architecture of complicated application. The applications can now be much better modularized making building complicated extensible applications possible. I never was against by-value LVOOP and I still find it very suitable for many but not all use cases. The lack of recursive calls was an near show-stopper issue for some projects but now in LV 8.5 it has been fixed. Thanks for the R&D team for this excellent improvement!

Over all I'm quite happy with current LVOOP in LV 8.5. This doesn't mean that I think it even close to being complete OOP implementation; there is still a huge amount of work to do.

Some improvements I'd like to see in LVOOP in the future:

• The current development process is simply too slow. Endevo GDS speeds up the development process significatly. However the native development process needs to be speed up a lot by making the process more fluent.
  • Placing class controls and methods is not simple and fast enough.
    
  • There are two few templates for creating new methods.
    
  • User should be able to create their own method templates that would integrate to LV Project context menu
    
  • Editing icons is not fluent and fast enough
    
  • One should be able copy a method from a sister class so that the icons becomes automatically correct and the class controls are changed
    
  • One should be able to create override methods from different templates as well, the default scripted override VI is almost never usable by any means
    

  [*]The lack of both build in create nodes comparable to new operator in Java as well as lack of build in constructors are an obstacle

  [*]The support for by-ref classes would still be nice to have

  [*]I need mixin inheritance everywhere and every day

  [*]LabVIEW build-in type should really be made classes as well so that they could be passed where LabVIEW Object is expected. For example currently AQ's binary tree map implementation doesn't function for any build-in LabVIEW types. This is a issue that encouter often when I try to make new tools. There is no common parent class for build-in LabVIEW types. There is nothing in principle that would prevent simply calling build-in LabVIEW types classes.

  [*]Class probes don't work for child classes

  [*]I'd like to be able to use inner classes (that have access to outer class private data)

There may be more issues but I simply need to go now Overall LVOOP is an excellent improvement to LabVIEW. Not having LVOOP would have forced me to move to other programming languages at least part time. Actually I'm still planning to use some other languages as well but at least now I can still use LabVIEW for most of the projects. Great job Aristos Queue & co. And thank you!

[i2dx]

QUOTE(Ben @ Aug 23 2007, 07:39 PM)

That may be just enough time for me to complete the paradym shift.

Ben

just to add some more explanation:

I am not against LVOOP in principle. But the only thing that counts in my business is to deliver good quality within time and budget, which means, there is little room for experiments. If I make experiments and my tools are buggy or are in their fledgling stages, that will cost me extra time, nerves and money. I'd simply like to avoid that.

I can state that I will use LVOOP, if I have an advantage in my business. In the meantime, I'd like to thank developers like Tomi for their patience and there enthusiasm to test and improve new technologies and AQ for improving LV - I hope you have enough stamina

[gmart]

QUOTE(Michael_Aivaliotis @ Aug 23 2007, 12:10 PM)

I agree with jaegen on this one. Single EXE build needs to be a future feature. This restriction alone will turn off many from adopting Classes. Let's not forget that people (including myself) have been building successful test systems for 20 years before classes were introduced. Even without classes, work can still go on as usual - until NI forces us to use classes (which they probably will). I'm in favor of classes, I'm using classes in customer projects, but the more gotchas you present, the harder it is to convince people.

I'm not sure what you mean by "gotchas". The current behavior is a result of the current mechanism used to build applications. It affects regular libraries as well but is not as big an issue there since a rename doesn't have the same impact as with a class.

We are aware of the need to improve how we build applications and are looking at how the process can be improved.

[Guillaume Lessard]

I have used LVOOP in one part of an application as I was refactoring it. The result was a little messaging library that I found quite satisfying, and as a result I'd like to use LVOOP some more! I was expecting to be able to do so after the new version came out.

However, the meat of my LabVIEW work involves the RT module, and so I still can't use LVOOP very much at all. That's very unfortunate.

[Mike Ashe]

I haven't really gotten into it in the last year due to the non-target deployment issue. Hopefully that will change in the next year. I've been working on a modularized RT (mostly PXI) system the past year and I think it would really benefit from LVOOP if we could get it down on the RT PXIs.

[Aristos Queue]

QUOTE(jaegen @ Aug 23 2007, 10:50 AM)

Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.

The "VIs not inside the EXE" bug (and, yes, I do consider it a bug) remains in LabVIEW 8.5. It is on the "must fix" list in the next LabVIEW version.

The end goal is to be able to store multiple files of the same name inside the EXE without mangling them.

QUOTE(Michael_Aivaliotis @ Aug 23 2007, 12:10 PM)

until NI forces us to use classes (which they probably will).

No. NI probably won't. There are very few believers within the walls of NI.

[Val Brown]

QUOTE(i2dx @ Aug 23 2007, 10:35 AM)

I hope nobody will force me to use classes. Nobody forces a C Programmer to switch to C++! And IMHO it's a bad idea to force a programmer to use a specific feature. If that feature gives him an advantage (faster, better, cleaner code, etc ..) he will use it. That would be the only "force" I'd accept.

I hope that Michael was using hyperbole -- it's not on any of the pallettes but I think it ought to be.

First of all I don't know how NI would "force" anyone to use classes. If anyone has any ideas on THAT "new feature" and how it would be implemented, I'd really like to hear it.

Second though I really don't see that using classes IS inherently any particular advantage -- not to mention the various competing "flavors" of OO implementation that are currently banging heads. As you point out, without CLEAR advantages to a new feature, most programmers doing real work won't -- and can't -- take the time to "play around" and see how it goes. In one very fundamental sense this is a kind of engineering in the sense that we are involved in "building" "devices" that actually "perform work" according to "specs and reqs".

Third it really doesn't make sense for NI to alienate and disenfranchise its long-standing, advanced programming community that has "come up" using dataflow. Why have dataflow-based programming precluded by enforcing classes? That may appeal to some who've "come up" using classes but it really deprives LabVIEW of one of its most definining attributes. LabVIEW without dataflow -- but with enforced use of classes -- is really just a "pretty face" on Visual Studio.

If this idea of compelling classes has any cogency at NI, I'd really like to know; and I'd really like to know who to talk to about making certain that this really BAD idea does NOT get implemented, even "accidentally".

Third