Object Oriented Polymorphism; Abstracting Data Types at the Method's Connector Pane

[paul.r]

You could create a library of all the buffer functions you want as vims, then create type classes that wrap up those functions if you want the encapsulation that a class provides. 

You could also store your elements as variants internally, and include a type input to all your read methods and make them malleable so the type returned matches the input type. You would still be doing the variant to data, its just internal to the method instead of on your calling code's block diagram. 

[rwunderl]

Thank you all for your input. I think I am coming to understand these things a bit better.

---

@drjdpowell wrote:

I'm working on a VIM-based buffer here, if the OP wants to see what it looks like.

---

I do not have 2018 on this machine, but I will try your solution out as soon as I get a chance.

I also found a blog post (Malleable VIs - class adaptation...) that seems to touch on these issues directly. I will try to wrap my head around it.

It's not that I'm stuck on keeping my exact implementation of the buffer classes, I just thought that was how it was supposed to be done. Then I hit so many obstacles on the way down that road that I thought I must be missing something. As it turns out, this seems to have been a common pain point that may be beginning to be addressed only now.

[wiebe@CARYA]

---

@rwunderl wrote:

I also found a blog post (Malleable VIs - class adaptation...) that seems to touch on these issues directly. I will try to wrap my head around it.

---

The title is a bit misleading.

It doesn't adapt the class, only the accessors. So you're still stuck with either on type of internal data (a dbl can be used to store integers or Booleans) or some kind of generalization (to variant or flattened string).

[Intaris]

Drop a few Kudos Here:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Malleable-Classes/idi-p/3910046