History of GOOP
Contents
V I Engineering VISTA Class Generator
Inspired by the implementation of the Config File VIs that shipped in vilib in LabVIEW 3.0, David Hoadley (V I Engineering Director of Engineering) and Stan Case (Senior Project Engineer) created a class generator that would dynamically create by-reference LabVIEW classes.
The generator would prompt the user to name the class, and then create a control (for private member data) and methods, to be filled out by the user later. The generation of the class was by copying of an existing class template that shipped with the class generator, and a very early implementation of LabVIEW scripting to rename and recompile the new class.
The reference used to distinguish objects was a datalog file refnum, with a single-element enum inside it - the data value of the enum (the text in the 0th element) defined the actual datatype of the class, prohibiting cross-pollination of object types (LabVIEW would break wires that were connected between different class types). All code in the generated class, as well as the generator, was pure LabVIEW. The VISTA Class Generator was bundled (along with other components of the VISTA product offerings) with the VIE LabVIEW Advanced Application Development Course. The course was later acquired by National Instruments, and forms the foundation of the existing LabVIEW Advanced Course.
The VISTA Class Generator was deprecated in 2000, and V I Engineering became the North American distributor and support center for Endevo GOOP and the GOOP Development Suite.
Endevo GOOP and the GOOP Development Suite
An excerpt from an OpenG discussion forum posting from Mattias Ericsson (Endevo project leader and main developer of the GOOP2, Wizard 2 and 3) to Jim Kring on: Tue 01 of Jul, 2003
The GOOP history began back in 1994 when Jörgen Jehander (one of the founders of Endevo) developed the first GOOP, actually taking advantage of his background as a C++ programmer and found a way of implementing OO in LabVIEW. This was a genuine LabVIEW implementation of the GOOP. There existed no Wizard back then. During 1994 and 1997 the GOOP went through many changes, especially the attribute synchronization and reference handling.
In 1997, a GOOP course, "LabVIEW System Design with GOOP" was held for the first time in Sweden and been held ever since and has also just recently started in the US.
In 1998-99 a cooperation began between Jörgen Jehander and Stepan Rhia from NI which started to developed the GOOP (the CIN based). The design was made both by Jörgen and Stepan, but it was Stepan who implemented both the CIN and the _goopsup.llb (included in LabVIEW 6 in vi.lib/platform). The reason why there is a CIN and not a LabVIEW implementation is that back then the performance was better with a CIN, but when LabVIEW 6 was launched (which has a much improved memory management) the benifits of using a CIN is gone. The GOOP Wizard 1.0, which might be download from ni.com, was developed in 1999 both by Jörgen and Stepan.
In 2002, Endevo launched a new GOOP Wizard 2, a new tool for creating and editing GOOP classes. This is not a new implementation of GOOP itself, but is only an improved Wizard with a lot of editing functionallity and also build-in icon generation. This Wizard is not distributed by NI, but may be bought from the Endevo homepage.
In 2003, a new GOOP, called GOOP2, is launched which has full support for inheritance (method and attribute inheritance, virtual methods and also static attributes) together with a new Wizard, the GOOP Wizard 3. This is sold as a new toolkit, GOOP Inheritance Toolkit. This new GOOP2 is a genuine LabVIEW implementation (no CIN, DLL or anything strange).
The GOOP Development Suite was acquired by National Instruments in 2014, and is now a free download from the LabVIEW Tools Network.
OpenG OpenGOOP
SciWare GOOP Developer
DataAct dqGOOP
As the name suggests, the dqGOOP design is based on a queue of a single element that encapsulates the private class data. Created in 2003 for LabVIEW 7, the architect concentrated on delivering a toolkit where the performance of the system was key. An excerpt from the dqGOOP website:
Most of the existing GOOP examples involve classes with relatively few objects that get created at the application initialization and destroyed at the end. What if you want to build an application applying OOP principals where there are hundreds or even thousands of objects and the design entails that one object may contain multiple other objects which in turn contain objects themselves?
I started to develop such an application and soon ran into the performance limitations of the existing GOOP frameworks... There was an offhanded comment on the Info-LabVIEW mailing list about how the queues in LabVIEW were improved in LabVIEW 7. Then I started to poke at the concept of using a queue as the data store for GOOP objects. Not only is the access fast, but queues have built in locking which means there is no need to create Semaphores or Occurrences. I used the new "Show Buffers..." tool and focused on creating the dqGOOP VIs with one priority...PERFORMANCE.
dqGOOP is free and can be downloaded from the DataAct website.
