LVOOP 101 - Class Conflicts

[PaulOfElora]

Looks like I've been booted back to LVOOP 101.  I've stepped just a bit off my map, and have stumbled.  Instead of doing what I've done before, and slavishly having child classes share all the same class data as the parent, and with each other, I've given my "Servo Motor" and "Stepper Motor" child classes different data.  The parent Motor class doesn't include these data which are unique to the child classes.  Alas, I get a class conflict when I try to use the Motor parent object to call an accessor VI belonging to the child Servo Class.

You can see in the snippet that a Servo Motor accessor method (obviously) will only work on the Servo Motor class object.  But the compiler does recognize that the 3 class objects are similar enough in type to allow array-ing them.

I think I had some vague, ill-formed notion that I could "override" parents' data, as well as methods, in child classes.  I figured that as long as I didn't try to make them dynamically dispatched I could get away with it.  Is this where I went astray?  Do I need to go back to enforcing my old practice of All Child Data = All Parent Data?  Confused again, paul

[DerrickB]

Hello Paul,

If you're not putting shared data and functionality in the parent class then what's the reason behind using inheritance? Generally speaking you don't use inheritance and static child classes to "hide" parent functionality. Anything you'd want to do generally on a collection of multiple class types where the child implements specific functionality you'd have as a dynamic dispatch call specified at the parent. If you know you want to specifically work on servos as servos and steppers as steppers then you'd never combine them into a single array; you could keep track of two arrays separately. Even if there is some shared behavior defined by the parent on the two types you could still track them separately but have access to calling VIs only defined on the parent to save writing code multiple times.

LabVIEW will always allow building arrays of classes as they ALL have an ancestor in common - the base LabVIEW Object class. It will try to be as specific as possible when figuring out what type to use on the output of the build array but again, you'll always be able to build an array of classes. The thing to do here would be to create an indicator from the output of the build array and see what class type it's using for the wire.

I'd recommend checking out Tom's introduction to LVOOP at https://www.youtube.com/watch?v=j2JkcC0CMEI&list=PLmF-6jvwRvVNVPfGxGPMsf3cZafT83oH8  and of course ask any follow up questions here!

[PaulOfElora]

Thanks Derrick - yes, without some kind of shared functionality, inheritance doesn't make any sense.  I do actually have only one function and one data variable that are common to both.

Turns out that I was doing silly things in one of the child's class data that was preventing me from calling a child accessor - I had moved some data around and got careless.  I was basically trying to access parent data that wasn't really there, doop! Appreciate your clarification, paul