Merging LVOOP and the Open Source GOOP Template

[Kurt Friday]

Hi Everyone

I've been tinkering with LVOOP and playing with ways to merge LVOOP and the Open Source GOOP Template. It actually hasn't turned out too difficult to take some existing demo classes built using GOOP Developer and edit them so that they use the LabVIEW class datatype. The immediate benefit of this is that dynamic dispatching (or virtual methods) are automatically handled, no more registering virtual methods.

The next step is to start investigating how to get GOOP Developer to auto generate the classes and also build children, I'm just starting to look at the scripting options and I'm sure its possible.

Demo code attached

Download File:post-1058-1162936616.zip

[klessm1]

Hi Everyone

I've been tinkering with LVOOP and playing with ways to merge LVOOP and the Open Source GOOP Template. It actually hasn't turned out too difficult to take some existing demo classes built using GOOP Developer and edit them so that they use the LabVIEW class datatype. The immediate benefit of this is that dynamic dispatching (or virtual methods) are automatically handled, no more registering virtual methods.

The next step is to start investigating how to get GOOP Developer to auto generate the classes and also build children, I'm just starting to look at the scripting options and I'm sure its possible.

Demo code attached

Download File:post-1058-1162936616.zip

Very nice... and very useful. I was looking into ways to create multiple LVOOP objects and still have data protection, and this looks good. :thumbup:

[Kurt Friday]

Cool, glad you like it.

I'll post up a few more demos soon, one demonstrating active objects would be interesting. At the moment I'm manually editing the existing demos described in the GOOP Developer Tutorial, but what I'll be working on very shortly is how to auto generate the code, which will be both challenging and fun. I'll keep everyone updated with how I'm progressing with that.

[klessm1]

Cool, glad you like it.

I'll post up a few more demos soon, one demonstrating active objects would be interesting. At the moment I'm manually editing the existing demos described in the GOOP Developer Tutorial, but what I'll be working on very shortly is how to auto generate the code, which will be both challenging and fun. I'll keep everyone updated with how I'm progressing with that.

Do you include the virtual table for backward compatability (code upgraded from 7.1.1).

[Kurt Friday]

Do you include the virtual table for backward compatability (code upgraded from 7.1.1).

At the moment the demo code is just a proof of concept, in the final GOOP Template for 8.2 that supports LVOOP there will be no virtual table, a lot of the inner mechanics will be stripped away.

[Kurt Friday]

I've done up another demo that incorporates active objects, inheritance and uses a plugin architecture. This demo is again built from one of the GOOP Developer tutorials where a DataSource object and a DataStore object plugin to a Logger active object. The DataSource class has two children, DataSource.Sine and DataSource.Square which simulate Sine and Square waveforms respectively. The DataStore class has two children, DataStore.Spreadsheet, which enables writing data to a spreadsheet file and DataStore.Binary, which enables writing data to a binary file. The Logger class simply reads the DataSource object and sends it to the DataStore object at the desired rate.

So far the merging of LVOOP and the Open Source GOOP Template is looking promising, any feedback would be great, hopefully not too far away will be a very cool by reference implementation of LVOOP.

The code is 6 Mb so I wont post it up here but you can download it from

www.sciware.com.au/LVOOPGOOP/

[Jim Kring]

I've done up another demo that incorporates active objects, inheritance and uses a plugin architecture.

Hey Kurt,

Great example! I have some thoughts...

In LVOOP, the class data (the GOOP class reference, in this case) is private, which means that a child (DataSource.Sine, for example) cannot read/write the parent's (DataSource) data. In your example, both the parent class (DataSource) and child class (DataSource.Sine) have LVOOP object data, which is their own GOOP object reference. This means that the LVOOP object data of a DataSource.Sine object has both a DataSource.Sine GOOP reference and a DataSource GOOP reference. However, all members of the DataSource.Sine (child) class use the DataSource.Sine reference and all members of the DataSource (parent) class use the DataSource reference. This means that the parent and child classes are not using the same GOOP object reference!

For example, DataSource.Sine.Create.vi initializes the DataSource.Sine GOOP reference. If this is passed to any parent class member, such as DataSource.Read.vi, then an error will occur, since the DataSource GOOP reference is null (recall that DataSource.Sine.Create.vi initialized only the DataSource.Sine GOOP reference and not the DataSource GOOP reference).

The solution that I have found, is for the base class to define a GOOP reference in its LVOOP object data, and for child classes to use the base class object reference. However, since the LVOOP object data of the base class is private, and not directly accessible by child classes, the base class must define protected (not private) methods called GetGoopReference and SetGoopReference, which the child classes can use to access the GOOP object reference. The child class constructors must use SetGoopReference to set the GOOP reference in the LVOOP data, when the object is first created, and the other child class methods must use GetGoopReference to get the GOOP reference in the LVOOP data, so that they can access the GOOP data.

I have modified your plugin example, to show what I mean You can download this example, here:

http://jimkring.com/LVOOP_Plugin_JK01.zip

My mod's are not very clean or complete -- it was a quick hack. Take a look at DataSource.Demo.vi to see what I've done.

Here are some of the changes:

• modified the DataSource.Sine LVOOP data, deleting the DataSource.Sine GOOP reference.
  
• added DataSource.GetRef.vi and DataSource.SetRef.vi protected methods for allowing DataSource.Sine methods to access the GOOP reference
  
• modified DataSource.Sine.Create.vi to call DataSource.SetRef.vi, to allow it to set the GOOP reference in the parent class LVOOP data.
  
• added DataSource.Test.vi to set a data element in the parent's data
  
• modified DataSource.Read.vi to call DataSource.GetRef.vi in order to get the GOOP reference
  

[Kurt Friday]

Jim, you are a wizard

That's really cool, you have solved an issue I hit when I was playing with merging the two, I couldn't run a parent method on a child just to operate on parent data, unless you used dynamic dispatching. I've had an initial play with your solution and it looks elegant, I'm going to have a deeper look this weekend and play with your ideas. This is going to be fun.

I'm still investigating what is involved in getting GOOP Developer to work with such a GOOP Template, the only hurdle is that scripting isn't exposed in 8.2, however where there is a will there is a way.