LVOOP vs GOOP

[Cory_K]

I've recently started toying around with incorporating LVOOP into my larger LabVIEW programs.

I have seen the terms LVOOP and GOOP thrown around, but I'm not entirely sure I understand the difference.

This is my understanding, please let me know if I am incorrect, or missing something.

  Both terms refer to using LabVIEW in an object oriented fashion.

  In both types of programming, you can create a class.

  Using this class, you can create both objects and methods of the class.

  The main difference would be how information stored/passed.

  In LVOOP, the actual objects are being passed around,

  whereas in GOOP, references to the objects are being passed, rather than the actual object.

Is this correct? Are there more differences?

Spoiler

I have a feeling Ben is going to jump into this discussion at some point  

[Broken_Arrow]

Cory,

I think it's just that GOOP is 3rd-party implementations of OOP whereas LVOOP is the internal OOP.

[Ben · Accepted solution]

LVOOP is native to LV.

GOOP was Edevo implementation of OOP that was implemented with the cooperation of NI.

They both allow implementing OOP in LV.

I have studied GOOP but never used it becuase of how it was implemented, using references. Acces to the private data was allowed using a Core that was a kind of uber-AE capable of string anything. This implementation restricted developer rom amaking changes to the Core and as a result, we limited to using what the core exposed which were COPIES of the dat in the Core. The COPIES part is what kept me out of the GOOP since my applications simply can not tolerate buffer copies.

The big plus for GOOP was it supported UML and could gen classes based on the UML or gen the UML from the classes (to a limited extent at least).

I believe it is no longer being developed (but I may be wrong there).

LVOOP has no knwolege of UML. It is very efficient provided i don't stupid stuff. It is also very flexible.

With the morder versions of LVOOP and the introduction of the DVR (data value ref) LVOOP can now pass refs to access instance of class data.

Ben

[Cory_K]

Ahh ok. LVOOP has provided all of the functionality that I have needed it for so far.

I was just curious what exactly GOOP was, but it sounds like LVOOP would work better for my applications.

That is interesting that GOOP passes copies of everything rather than passing the actual object,

seems like that would cause quite a number of issues with large data manipulation software

Thanks for the explanations!

[Broken_Arrow]

Ben explained it better

[F._Schubert]

You can find information about GOOP on their community page. GOOP is under active developement (there was a new release comming with LV2010). There is a free community edition available (I think it's limited to 10 classes). The editor is based on uml and templates, I think you also can make your own templates to get your uml class implemented in LVOOP. Some people from the GOOP team also hang around at LAVA.

Felix

[Mark_Yedinak]

It should be noted that there were other implementations of GOOP back in the day. Endeavo seems to be the one that won out and is still around. In addition GOOP started outed before LabVIEW had any native support for OO programming and because these implementations were add ons on top of native G they weren't really able to fully implement all as aspects of classes. A perfect example is protection of the private data memebers and methods.

[richjoh]

Endevo was sold and bought out (I believe the orignal developers (college profs) have nothing to do with it.

I came across a company's code that used it (and they bragged about it) and I can tell you first hand, it appeared more pain that glory.

OOP is nice in theory but since Endevo GOOP dynamically called its class methods and so on it was tedious to debug in LV7.1. VIs are set ReEntrant to deal with the dynamic calls (and LV7 didn't allow debugging of Reentrants unless unchecked Reentrant property!  Experienced LV guys had trouble debugging the code since it calls VIs at runtime (way outside of data dependency thinking). OOP methods using G alone would have  simplified code and debugging issues. Endevo fit a square peg in a round hole and made $$$ from it.

Notice NI is quitely allowing GOOP to wither away.....

[F._Schubert]

richjoh, that's not fair. In LV 7.1 you don't have any native OOP option. Those days, there where several tools available that allowed you some OOPing (like GOOP) at least. GOOP now uses the native LVOOP as a basis.

And don't forget:

It was the glorious days of real hacking then... ever saw the 'ExternalNode' of a storage VI?

Yes, we really had a map with a lot of places marked as 'beware of dragons'. Today, there is just a big maze around them, so you don't find them any more.

Felix

[richjoh]

How can you say "GOOP now uses the native LVOOP as a basis", its called Labview OOP not GOOP. What are the benefits besides maybe backward compatible (today) with legacy Endevo classes (I'm guessing here). 

Endevo never considered the debugging night mare and plenty of Endevo bewildered GOOP is running on test station. Yes the whole Endevo GOOP is a hack job on Labview, (ever look at the unlocked Endevo class creators (lots of overhead bloat LV code). Please explain how Endevo GOOP help out your projects.... enlighten me.