Organizing class inheritance combinations

[AristosQueue (NI)]

Not multiple inheritance, since there'd be no *requirement* for conpane matching and there'd be no runtime type casting allowed, but we would have something close to template instantiation in C++ which resolves as long as the syntax matches, regardless of whether the syntax means the same thing (which is why functors work in C++ templates). In this case, even if the conpane was wholly different but compatible, the substitution would be allowed. It doesn't seem like a bad idea to me, but I haven't really thought it through, so there may be something lurking if I dig (probably is since others saw it years ago and waved me off of that approach, but LV has evolved since then).

[Intaris]

---

@AristosQueue (NI) wrote:

(which is why functors work in C++ templates)

---

If that's not a typo, I just learned a new word.

Seems legit, Wikipedia has an article on it which I do not understand.

[crcarlin]

---

@for(imstuck) wrote:

---

@AristosQueue (NI) wrote:

Your observation was correct. And yes, I am talking about poly VIs spanning the object trees.

---

This is blowing my mind. If someone has time, could they draw up a quick example with code? I learn better from pictures; it's why I program in LabVIEW.

---

for(imstuck): I'd say skip all the fancy object talk for a second and simply note that the polymorphic VI treats different object classes as different types.

In fact, this polymorphic approach is simplistic and lacks some of the features from the rest of the LabVIEW OO (e.g. Call Parent Method) so I'd avoid the mind blowing and talk of trees entirely.

[drjdpowell]

---

@AristosQueue (NI) wrote:

For the record, there's no good reason for the limitation... it just happens that poly VIs have some ancient code that made them resist dynamic dispatch VIs as members and I've gotten very few requests to fix that, so it is has been at the bottom of the priority list, especially since the "static dispatch wrapper VI" workaround exists.

---

Please fix that.  

[AristosQueue (NI)]

---

@drjdpowell wrote:

Please fix that.  

---

I don't work on classes any more. Been spending the bulk of my time working outside LV entirely and a smaller amount of time working in G code... the only features I've had in two releases have been pure G code (and I'm thrilled with this, btw). But I'll pass your request along. 🙂

== AQ