Search the Community

Hi, following some suggestions for improvement of LVOOP which i'd like to see in LVOOP in a future version. Please note that all those questions refer to an architect level! 1. Constructor: LV enables the programmer to name a VI equally to the class the VI contains. So it is possible to generate a "constructor", even though we don't necessarily encourage the user to do so. See attached example for this. The idea is to create a "constructor" VI which creates an object and calls required initialization routines internally. An example would be configuring an instrument for a specific HAL class. An often used feature for such constructors is "overloading", so having different sets of parameters while keeping the same function name. Currently this is not supported in LV. What do you think about this feature when talking about constructor VIs as explained above? 2. Destructor: This is tricky since most OOP guys would expect this to destroy the object, which in case of LV is obviously most often not the case. Still, it could be used for de-initialization for the user of the class. See attached example for this. 3. Polymorphism/Inheritance: In some cases of OOP, it would be beneficial to have polymorphism for class functions, sometimes directly connected to inheritance. Small example: Class "DataAcquisition" defines general IO functions. Class "AI" inherits from DataAcquisition, overriding all AI functions. Polymorphism should be used for DataOut since Data could be a waveform, a 2D array, .... Additionally, polymorphism could be used for inheritance directly if parameter types depend on the specific class. E.g. aggregation collects different class objects. 4. Singleton: One can create a singleton as seen in attached example or on https://decibel.ni.com/content/docs/DOC-13462. The problem i got with this singleton pattern is that the object within the DVR (the singleton) cannot be used for dispatching, hence no inheritance override possible. In order to get this to work would require the following change: The connector pane terminal of type "LV Object" and "DVR to LV Object" shall be configurable to "Dynamic Dispatch Input (Required)". Currently, this option is only working for "LV Object". 5. Overloading: As already stated in point 1., overloading would be a nice feature for constructor VIs. Adding to that, overloading could be a nice feature for inheritance as well. So the override function can add (not remove!) additional parameters without the need to define a generic data container (e.g. variant) in the ancestor class. 　 I know that all features, except 4. Singleton, can be solved differently, best done by appropriate wrappers. But i think that some developers could profit from LV opening up to more a common OOP approach used by other OOP languages. @NI R&D: If some of these are already on schedule, please let me know @All: Please discuss! thanks, Norbert Singleton.zip ClassConstructor_Destructor.zip