Parent Grandchild Inheritance - OOP

[AMP12]

I have a two part question I am looking for help on...

1. Data inheritance from a parent object to a child object, how do I make the parent data specifically available on the child wire?  I understand that you need to use the parent accessors to obtain the parent data on the child wire.  When I do so, all I get is the parent control's default data.  Any updates to the data I've made since instantiating the parent class are not reflected in the child's wire.  Why is that?

I was shown a technique used for the dynamic dispatch of classes with the Preserve Run Time Class.vi, but this doens't work outside of dynamic dispatch (it seems).  I've also played around with various combinations of the To More Specific Class.vi, both times getting errors, 1446 and 1448 respectively.

I managed a work-arround by using a functional global variable to store all the parent data, then retrieve it in the children to utilize it.  Afterward, I found this forum post which also suggested the same thing.  Doesn't this technique go against OOP inheritance principles?

2. Assuming problem #1 above can be solved, is there anything special I need to do to pass parent data to a grandchild class and skip the child class?  I have a spot in my hierarchy where two of my classes are essentially placeholders for future growth and better organization currently (see the attached screen shot).  Support.class holds GPIB information for all devices in the child classes.  So Stand(ard) and Misc.HW classes are really not doing anything.  The GPIB data needs to be accessed in the Source and Switch classes where it is applied to the dynamic dispatched great-grand child classes.  Can I simply skip Stand and Misc.HW classes and inherit the data directly to Source and Switch?

[Mark_Yedinak · Accepted solution]

Class data in LabVIEW is always private and only accessible to children classes through accessors. Also, LVOOP is by value, not by reference. So, if you branch a wire you get two copies of the class instance. A change to the data on one wire will not be reflected in the other instance on the other wire. You can make your class behave like a by reference class if you use a DVR to store your class data. You would create the DVR when you create the object. You would release the DVR when you destroy the object. Inherited classes always have access to its base classes protected and public methods. Therefore a grandchild class can directly call the grandparent's method provided it is either protected or public.

[drjdpowell]

Re (1), if you post some code, it is more likely that we can see what the issue is.  

[AMP12]

Mark,  Thanks for the reply.  Your method is the work around that I am using currently.  I'm trying to find out what I need to do to get the data placed onto the child class wire once it is changed on the parent class. I can not find any techniques to do that.  I am using the parent accessors to get the data off the child class wire, but All I can access is the values originated on the parent class wire, not any updates since initialization.

drjd, Please find the atatched example I put together.

I hope this clarifies things for everybody.  I'm obviously missing something trivial here.

[AMP12]

Doesn't look like me attachment can through...

[Mark_Yedinak]

---

@AMP12 wrote:

Mark,  Thanks for the reply.  Your method is the work around that I am using currently.  I'm trying to find out what I need to do to get the data placed onto the child class wire once it is changed on the parent class. I can not find any techniques to do that.  I am using the parent accessors to get the data off the child class wire, but All I can access is the values originated on the parent class wire, not any updates since initialization.

drjd, Please find the atatched example I put together.

I hope this clarifies things for everybody.  I'm obviously missing something trivial here.

---

Use a DVR in your parent. Create a cluster of your data and have your accessors access the data via the DVR. This will allow the data to be seen by any branch of the wire. This is the by-value/by-reference conundrum.

[AMP12]

Hope this works this time...

[drjdpowell]

Unfortunately I don't have a working LabVIEW computer at the moment, so I can't look at your example.  But I just wanted to make sure you understood what "to more specific class" does.  It changes the class type of the wire; it does not change the class of the objects on the wire.  If you try put a parent-class object onto a child-class wire it will fail, and a default child-class object will be output instead.  If you call parent-class methods on this new child, they will return default values.  That, or something like it, may be the source of your problems in (1).

Re (2), btw, you can just leave the placeholder classes out; you can always add them back in later.

Oh, and a suggestion: don't do by-ref classes, at least until you have worked with by-value classes.

[Mark_Yedinak]

---

@drjdpowell wrote:

Oh, and a suggestion: don't do by-ref classes, at least until you have worked with by-value classes.

---

Actually I would say it depends on what the class represents. If the class is representing a real-world phyiscal object then I don't think a by-value instance is the right way to go. If you end up branching the wire you would effectively clone your object. If the object instance represents a real device you would want them to be consistent. If a change is made on one branch of the wire you would like it to be reflected on th eother branch as well.

Messages howver are a perfect case for a by-value object.

[drjdpowell]

---

@Mark_Yedinak wrote:

If the class is representing a real-world phyiscal object then I don't think a by-value instance is the right way to go. 

---

There's many ways to do by-ref, and they are all more complex than by-val.  And one needs to understand the basic by-value LVOOP in order to avoid getting in to trouble with a by-ref implementation (note the FGV global that AMP12 introduced).  One of the simplest and cleanest by-ref implementations is just to put a by-val object in a DVR reference, so writing a by-val class for a real-world object isn't a dead end.  You can also easily reuse the by-val object inside a different by-ref framework (personally I use an asynchronous "actor" for each real-world object, with the actor's com method being the reference).

So I still suggest AMP12 concentrate on understanding by-value dataflow first, by-val object in DVR second, and put off any complex by-ref setup for a long time (if ever; it being tough to design a better by-ref structure than a DVR).

-- James