Why does the Parent class not report the Child class data in LVOOP?

[Mark_L]

Attached is a practice program I wrote to learn about inheritance with LVOOP.

My impression of OOP is a Parent class describes the object type.  Then the children inherent the parent's description.  The child can also have addtional qualities but it always contains the descrition of the parent.  If a child does not have a VI with the same name as the parent then the parent VI will be loaded and run.  

My questions:

1) Why does the Parent.lvclass:Read.vi not report "Child" in the string indicator when the Child write VI was dispatched?

2) Is the data from the Child completely not seen by the Parent even when it has the same definition (that is String)?  I understand the Parent should not know anything about the unique Child items but I would think it should know about the common items that the Child inherited.  

Here is my code example:

[James.M · Accepted solution]

Those are two different datasets. The Parent class has a cluster of data containing String, the Child class also has a cluster of data containing String, but both of these Strings are separate.

This can be made apparent, by changing the names of the strings to match their respective classes:

What you want is for your child class Write VI to access the parent class's data. You can do this with a simple data member access VI within the child VI:

[Kevin_Price]

I'm on an older version (LV 2013) and couldn't open your example, but I think I have a guess.

It appears to me that both your parent class and your child class define a 'String' element in their private data.  Honestly, I didn't know that would be allowed.  In LVOOP, the child already inherits all the parent's data elements and shouldn't create its own new copy with the same name.  

I can understand your thought process for supposing that just as member functions *need* to be defined with the same name as the parent, you might suppose that the same applies to the private data.  It doesn't.  Even though the child class private data starts by showing no contents, the *reality* is that it contains the inherited parent data without showing it in the class definition.  The frame of mind of the lvclass is to show you only the private data that is *specific* to the child.

That said, access to that parent data from a child object may require you to use accessor functions or to do typecasting from child to parent.  I typically define accessor functions that are either public (for the general API) or protected (if only meant for access from self or children).  

-Kevin P

[Norbert_B]

Adding to James' reply:

You need separate methods to access the fields of each individual class. That means:

- Your parent read method only accesses the field of the parent class

- To access the field in the child you have to define a separate method (VI) in the child class itself

- Identical names for methods in inherited classes are only allowed for dynamic dispatch methods. The child method may call the parent method to add access to the field inside the parent part of the class; without the call parent method node, the parent field cannot be accessed inside the child

=> You can chose to have the read as dynamic dispatch. If so, the child method either accesses only the child field (no "call parent method") or only parent field (only "call parent method") or both ("call parent method" and using unbundle to child field). Its up to what you implement.

If you are not using dynamic dispatch, the child method has to have a different name and cannot use "call parent method". However, you can always use VIs from the parent class on child objects (as you already do).

Norbert

[Norbert_B]

---

@Kevin_Price wrote:
[..]  Honestly, I didn't know that would be allowed.  In LVOOP, the child already inherits all the parent's data elements and shouldn't create its own new copy with the same name.  [...]

-Kevin P

---

Kevin,

I concur that LV should at least warn you about possible misunderstandings. Technically, the classes are separate clusters, so identical field labels are not an issue. From management point of view, sharing label names in inherited classes could easily create nightmares......

So general recommendation: Each class should include unique label names within the inheritance hierarchy.

Norbert

[Mark_L]

Thank you all for helping me understand this.  

From your  comments it would seem using the Call Parent Method VI is an acceptable way to solve this issue.  It puts the text "Child" into the Parent class string.  

The coersion dot would be fixed by using the "To More Generic Class" native showing that the programmer undertands the child class does not have a Read.VI.  

[James.M]

Yup, it looks like you did pretty much what I was trying to show in my reply, except simpler because you use Call Parent (which I didn't know was a thing until just now) instead of a separate data access VI.

[mikeporter]

Unlike Zaphod Beeblebrox, normal parents (human or programmatic) can't inherit from children. What if you had more than one child, what then?

Mike...

[Ben]

---

@mikeporter wrote:
Unlike Zaphod Beeblebrox, normal parents (human or programmatic) can't inherit from children. What if you had more than one child, what then?

Mike...

---

Spoiler

I did get my gray hair from my son. Does that count?

Ben

[Mark_L]

Thanks James.  I didn't think about the Data Member Access VI.  I like the way it works by creating it with the right click menu.  

I also found that the coersion dot can be eliminated by setting the Read.vi class input terminal to Dynamic Dispatch.