Here is a link to a document describing the decisions made in the current implementation of OOP released in LabVIEW version 8.20.

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

I've also attached a PDF version.

This post has been edited by Michael_Aivaliotis: Jan 19 2007, 05:52 AM

a really interesting document. thank you for posting ...

An updated URL is now available:
LabVIEW Object-Oriented Programming: The Decisions Behind the Design

This location is the permanent home of the document. If there are updates to the document, they will be made at this URL.

The doc says that they view the purpose of GOOP as encapuslation and inheritance, but much of the purpose of encapsulation is BECAUSE of pass-by-reference issues. I also found their argument for pass-by-value in standard G interesting, as they argue its to enforce the notion of parallalism which could have two independent processes referencing a variable in a non-standard order.

Although, in practice, the problem I find more often is that I'll have globals in my code and have one part of the code update a state boolean global and another part of the code will come AFTER the update, read it, and Labview still hasn't been updated the global yet so it gets the wrong value anyway. This, I find, to be more insidious because I expect the update has occured already even when it hasn't. So these days, when I want to be sure an update has happened, I end up writing to it AND polling it to make sure the readback = the write. Dulp! Perhaps Labview is biting off a bit more than it should chew in GOOP. Incidentally, now that I'm writing about it, I really think this is something that should be fixed...I'm sure someone will say something about semaphores next. <g>

This post has been edited by brent99: Aug 15 2006, 06:30 PM

Yes, I also think many important use cases for OO also requires by-reference. In your example with parallell loops accessing the same data instance by-value makes no sence. Or for instrument control I would probably prefer having control of when objects are created. But I also think there many cases where you could benefit from the flexibility that classes and inheritance could give and it does not really cause any functional issues in the design that objects may get copied. For example you may like to read the same kind of data from different sources, first your input data comes from an Exel file and then you upgrade to XML files. This could be solved by using inheritance and sub classes for each file format making it possible to add new file formats without braking or modifying existing code.

Jan
www.endevo.se

The article was good, thanks NI for the article. One thing however annoys me quite a lot in the article. It kept repeating that the lack of properties in LabVIEW OOP is due to the fact that scientists and engineers are not formally trained for programming and therefore couldn't use properly any fancy features of programming languages. I strongly disagree with this view.

I think that most professional programmers are not really that, well professional. At least no more professional than LabVIEW users are professional programmers. Fromal training doesn't really teach people programm well, programming is learned by practise. There are very talented LabVIEW programmers out there as there are very novice LabVIEW progrmmers out there. But the same thing applies for Java and all other programming languages.

NI could easily package different kinds of product packages for different kinds of programmers. For example LabVIEW base package didn't have to include by-reference objects whereas the professional package would include these.

No that LabVIEW OOP has been launched, I'd appreciate if NI would publish design patters on how to cope with the issues that cannot be coped using the methods in popular object-oriented design patterns due to lack of features in LabVIEW OOP implementation.

That should be taken as "most programmers in any language can't use some of the features from C++ that were left out."

James Gosling was the designer of JAVA. He once gave a presentation on why JAVA's design decisions were made. One thing I will never forget is why JAVA does not have operator overloading like C++ does. "People were doing dumb stuff with it... like using the left shift operator for output!" The standard template library for C++ uses the left shift operator. Gosling's inditment was that the code becomes hard to read if these symbols become so context dependent that the code is no longer generally understandable. In the case of the left shift operator, that's probably ok because very few of us actually use left shift these days -- we don't need to squeeze that bit of performance out when multiplying by two anymore. But as the + became used for add, concatenate, append to file and other things, code clarity was lost. So JAVA didn't include this feature.

C++ is a masterpiece of language design in so many ways. It has capacities to express concepts beyond the dreams of most developers. It is the language for James Joyce. But most of us read Dr. Seuss. Many of C++ most advanced features are never used, and when they are, they just raise questions among a lot of other developers about "what the heck does this do?" A classic example is "class X : protected Y { };" What exactly does that do to the inheritance rules?

JAVA tried to refine OO. LabVIEW aims to take it to a whole new audience. Over time, features may be added that only show up in the Pro version. But the fundamentals were rolled out in LV8.2, and these are the pieces that will be common at every level of LabVIEW expertise. It isn't so much that LabVIEW users can't use the fancy features, its that many don't want to worry over whether they should or not. LabVIEW lets you focus on the project you're working on more than the code you're writing to do that project. We constantly balance power versus interference. It is our strength. And our weakness. And, fundamentally, it is our niche in the programming world. We aim to fill it well.

Interestingly even though you cannot overload operators in LabVIEW you can "overload" method icons, that is create a method with exactly the same icon. This has the same result in code readability than operator overloading, since icons define "what you see" instead of VI-names.

True. Not much I can do about that. ;-) But at least at the names level I can make sure that the common errors introduced by overloading don't happen to LabVIEW programmers the way they happen to C++ programmers. I've spent days debugging that type of error in C++.

Thank you for that Aristos, I agree with you in this issue. And despite all the critics I have given on LVOOP, I still think that even the present implementation of LVOOP is a great advancement.

I also like your new icon (below)

I think represents the fact that LVOOP doesn't have by-reference objects and that you have to use queues to get by-reference behaviour for the objects. Perhaps I should ephasize that unlike most of people here, I agree with you (NI) that it was the only possible choise to implement LVOOP was by using objects-by-value, although I don't see why objects-by-reference couldn't have been implemented on top of that. Perhaps you will, perhaps you will... *hopeful thinking*

Hi Everyone,

This is my first post on LAVA. I have learned LabView programming by trial-n-error over last one year while I was working on a project for my ME thesis. I have implemented a majority of my application as Matlab code embedded in Mathscript Window in LabView. Now I have to implement another critical module in my LabView application which requires me to implement Fuzzy Logic scripts in OOP form. There is going to be lot of data analysis and this application is real time. I am wondering if I can use LVOOP to program my module. Is LVOOP the best option for me to implement this OOP code in LabVIEW or can i get away with some other option. In the past I have done OOP in Java and C. I am an amateur LabView user.

I've already read the FAQ and Descision behind the design in NI-Zone section but still cant make up my mind. I have tried GOOP from sciware too but m still confused .

If you all think LVOOP is the right choice for me, then can you please suggest some usefull turtorials which explain with examples.


Thanks a lot in advance.

This post has been edited by bhupesh: Jan 19 2007, 03:52 AM

I can't believe I haven't posted this link to LAVA before:
http://zone.ni.com/devzone/cda/tut/p/id/3573

This is the LVOOP FAQ. It answers a bunch of questions and, at the end, includes links to tutorials, examples, Powerpoint slides, etc.

Hi,

you mention Real time, do you intend to run your program on an RT-platform?
If you are, I don't think LVOOP will work, since it is yet to be released for the RT platforms (if I'm wrong, Aristos will probably jump in and correct me).

/J

Hi Aristos,
The link u posted is non-functional (Internal error on the NI server)....
Could you please refer me some other sources......
by the ways I have already read the LVOOP FAQ's on NI, if that is what you were suggesting me.



By real-time i mean that I intend to build an executable and run my exe for a real-time process i.e. patient monitoring in the operation theater. My application is a state-engine (I am not using any other RT-toolkits available in LabView) based approach which i am currently testing in real-time.

Thanks!