Is this LVOOP implementation valid

[AristosQueue (NI)]

---

@Intaris wrote:
It's probably bad design but I personally like quoting Star Wars when I have to do upcasts downcasts like you have pointed out : "I have a bad feeling about this."

---

That's a good feeling to have generally -- downcasts are something to watch out for as they are a red flag. But this is a case where, based on the information presented here, I think the design is correct. Downcast nodes are to be avoided, not forbidden. 😉 

[Intaris]

Hmm.  What's the official "up" and "down" in upcast and downcast.....

I suppose "to more specific" and "to more generic" is a lot more robust....

[AristosQueue (NI)]

I established that at the dawn of classes in LabVIEW to avoid exactly these problems. 🙂 The online help, the LV Class Hierarchy window and all published documentation from NI places parent classes at the top and child classes at the bottom. To More Generic is equivalent to upcast. To More Specific is equivalent to downcast. I have done my mighty best to make sure every single lead LV user who got trained in LV classes by me always drew the relationship that direction (and so propagated it out to those that they trained and so on), not because it is better one direction than the other but because these conversations are SOOOO much easier when everyone knows the direction we are discussing! And, yeah, "Generic" and "Specific" address the problem, but people do tend to fall back on terminology from other environments.

[AristosQueue (NI)]

The family terminology that we use for LV classes (because it localizes well and because we found users were much more inclined to keep the definitions straight mentally than "base" or "super" or other terms) conveniently matches the directional phrasing, i.e., the terms "ancestors" and "descendants", where descend is downward directionally.

[GregFreeman]

---

@Intaris wrote:

Are you sure you need Strain channel to inherit from AI Channel at all?

Can the same not be achieved by compositing the objects instead of inheriting?  I would consider having the Strainchannel linked to the AI channels in the parent object but not inherited from them.  Is this something which would be feasible?  It depends a lot on what type of operations you're doing on your channels whether such an approach could ever be feasible.  It would simply declare a strainchannel to be a seperate entity which USES an AI channel.  Operators on the AI channel which need some intervention for proper Strain measurements would need to be overridden.

It's probably bad design but I personally like quoting Star Wars when I have to do upcasts like you have pointed out : "I have a bad feeling about this."

Shane.

---

Thanks, Shane. I'll have a look at this concept tomorrow when my brain may actually process it, but I think I get what you're getting at. I may just have to draw up a small example myself for it to click. Maybe my issue here is that I'm trying to move stuff to the base class purely based on the fact that "every measurement will have channels" and "not making duplicate data in my child classes." This is causing upcasts which is resulting in greater pain than just having some duplicate data in children that hold their specific channel types. But that takes me full circle to thinking, maybe it's a design issue. It sounds to me like you're almost flipping the design inside out, which may be the better option. I'll let you know how it works out. If you find it in your heart to make a quick example, I surely wouldn't complain 😉 

[Intaris]

---

@AristosQueue (NI) wrote:

I established that at the dawn of classes in LabVIEW to avoid exactly these problems. 🙂 The online help, the LV Class Hierarchy window and all published documentation from NI places parent classes at the top and child classes at the bottom. To More Generic is equivalent to upcast. To More Specific is equivalent to downcast. I have done my mighty best to make sure every single lead LV user who got trained in LV classes by me always drew the relationship that direction (and so propagated it out to those that they trained and so on), not because it is better one direction than the other but because these conversations are SOOOO much easier when everyone knows the direction we are discussing! And, yeah, "Generic" and "Specific" address the problem, but people do tend to fall back on terminology from other environments.

---

This is true.  I never looked closely at the "to more specific" et al and they really do all have the parent at the top.

I'll do my best to adapt.  I've been describing it as the opposite for years.  Where the heck did I get that nomenclature?

[AristosQueue (NI)]

---

@Intaris wrote:

I'll do my best to adapt.  I've been describing it as the opposite for years.  Where the heck did I get that nomenclature?

---

Smalltalk? I've seen programmers in that language speak of "root class" and draw trees with the root at the bottom (which makes sense since that's where roots should be).

[Intaris]

Smalltalk.  That's probably it.  I have a friend (pharmacist by profession, gifted Borland programmer by choice) who lokes giving me very in-depht stories about the origins of nearly all major modern programming languages (including smalltalk ).  That could very well be where I have it from.