Which OOP to use

[cmrukcom]

Dear all-oopers,

So National Instruments have joined the party with LVOOP(8.20) it would be really useful to have a succint appraisal of all the OOPs that currently exists - I now know of 5:

Endevo GOOP

Sciware GOOP developer tool - using OpenGOOP I believe

the orginal OpenGOOP

Labview 8.20 OOP (LVOOP)

dqGOOP

There have been discussions recently about how LVOOP doesn't do calls by reference, only object calls by value , and a degree of reasoned argument from NI as to why this is. This particular issue seems to drive away my friends the OO programmers so it would be useful to know which of the other OOPS support this OO feature, amongst others.

I guess I am looking for someone who knows this field to summarise which features are supported in which OOP - (call by ref/value, inheritance, overriding, etc) and what are the particularly good features of each of the OOP approaches.

cheers

Kurt Haselwimmer

[didierj]

There was a poll here.

For my part I started with original GOOP (that one from the NI-forum with the password protected vi's :thumbdown: ), moved to openGOOP and now evaluating Goop Developer 2.0 and LabVOOP.

Which version you want to use, depends on your needs.

"Real" OO implementations (with inheritance,...) are Endevo GOOP, Goop developer 2.0, and LabVOOP:

Endevo GOOP has an impressive graphical Project tool,

LabVOOP is native LabView.

The other ones are older and do just implement static classes.

[Aristos Queue]

Which version you want to use, depends on your needs.

"Real" OO implementations (with inheritance,...) are Endevo GOOP, Goop developer 2.0, and LabVOOP:

Endevo GOOP has an impressive graphical Project tool,

LabVOOP is native LabView.

The official NI position is this: Both GOOP classes and LabVIEW classes are useful. They serve orthogonal use cases and you may well use both types in the same application. Comparisons should be based on program requirements and choice made accordingly. The core data of your GOOP Toolkit class may be a LabVIEW class. For details on this, take a look at this thread:

http://forums.lavag.org/index.php?showtopic=3788

[i2dx]

which OOP to use?

hmm, I think I will stick with my old Action Engines and will try to replace them step by step with LVOOP, where it is usefull.

First of all I think - because it's a paradigm change - it's a change in your head. You have to get rid of good old habits and see what's the best (most efficient, most simple, etc ..) way with the new unfamiliar features. I will approach to this topic with time, respect and with caution ...

Somewhat OT (my comment to the intense discussions about LV 8.2):

We are seeing big changes in LV now, and I think we have to be patient. There has allways been a "lack of functionality" in new invented features in LV, like the event structure in LV 6.1, which became "really usefull" in LV 7.0.x etc. Now LVOOP is the first implementation, and the feedback of the users will push it in the right direction - or the other way round: making a release is the only chance for a company to reach a wider range of developers, you can't make beta-tests for years I am confident, that NI will do a good job and sooner or later we'll again get a release like 7.1.1 - which was allmost perfect .

On the other hand, I can understand everyone who is ranting: some month ago I was taking LV 8.0 into production without sufficient testing, one of the results is a well know thread in this forum

cheers,

cb

[Jan Klasson]

Some more GOOP info...

The only OO support for by-value is the native OO. All external implementations you listed provides by-reference semantics. NI implemented the feature we couldn't provide externally.

In addition to the listed GOOPs there is the free GOOP Wizard 1 download from NIs site (developed by Endevo-NI). The run-time repository is based on a CIN node and object data is streamed. Endevo GOOP Wizard 2 is a better tool (icon editors, class renaming etc) on the same GOOP architecture.

About the Endevo GOOP Wizard 3 (which I know best for some reason):

You will find better run-time performance for object data read/write in object repositorys based on Queues or un-initialized shift registers. Endevos GOOP Wizard 3 (with inheritance support) is based on un-initialized shift registers. Inheritance is nothing without virtual methods which is provided by Endevos Wizard 3. These provides the same behaviour as the Dynamic Dispatch VIs in the native OO. But we implemented them using VI server which actually turns sub classes into potential plug-ins. There is also protected attributes (meaning attributes can be inherited from base classes). And also a concept we call Class Attributes (aka static attributes/data), this is attributes belonging to the class so it is used for data to be shared by all objects of a class.

There is also the G++ from the German company Vogel Automatizierung but I am not sure if that is around any more.

Jan

www.endevo.se

Shameless plug: The Endevo UML Modeller is the only UML tool with code generation and reverse engineering for LabVIEW. It currently supports only Endevos GOOP.