I have an class Communicator that knows how to pass objects of class Packet from one program to another. I want Packet to be able to hold any kind of information. At the moment, Packet holds a string of a certain structure, but at a later point it might have to hold integers, doubles etc. Ideally what I would like is a method Packet.getData() that returns whatever type of data it holds, and method Packet.setData(value) that accepts different parameters. I though at first to use inheritance and overriding, but in Labview all the connector panes must be the same.
I don't want to use variants because then I have to write decoding methods for each datatype, which makes the whole thing much less flexible and more cumbersome.
Can I make getData() and setData(value) polymorphic? Is there a better way to do this?
I don't think I understood you. You said that I can do this if the VIs are not dynamic dispatch VIs and then said it would be a good idea if they were? Is there a way to do this without polymorphic VIs?
Also, I was intending to have it dynamic dispatch, even though it's not absolutely necessary. My original idea was to have an abstract Packet that has children of different Packet types with different data (you can see I come from a C++ background, yes? :)). I quickly found that all the children have the same pane and you cannot override functions as in C++ with different inputs/outputs.
Thanks for your help, I'll try the no DD/poly route for now.
I meant that it might be a better idea if you do move all the type-specific code into the VIs which belong to the class, but whether that's practical or correct depends on your specific case. That way, you call a DD VI (Do Action.vi) and it dispatches to the correct class. That means you don't need to access the actual internal data outside the class.
If you still want to set the data using a common VI and your data types are encapsulated in a hierarchy of classes, then you can create VIs which will convert LV data (let's say a double) to your data (let's say double.lvclass). These VI do not have to belong to any class (nor do they need a class input) and you can make them polymorphic. You can then push the resulting object into your packet and it will fit because the packet holds an object of the parent class. If you want to get the data, you can write a get VI which does the same, but since polymorphism is edit-time only, you will need to supply it with a datatype to convert to (thus basically coming back to your variant design which you wanted to avoid).