Allow for ABSTRACT classes/functions in LVOOP

[Intaris]

I would like to make a small workind change on another suggestion found HERE.

I would like to be able to declare LVOOP classes as ABSTRACT.

One example is a spectrometer class I have developed which provides much of the needed functionality but which is not designed to actually DO anything (Get name, Set Name, GET calibration coefficients, SET calibration Coefficients and so on).  At the moment I can instantiate an object of this class as with any "VALID" class which then just returns an error at run-time because the functionality is not complete.

By preventing users from (either willfully or accidentally) dropping what is essentially an abstract class onto the BD of a program we could prevent some awkward bugs.

Shane.

[AristosQueue (NI)]

> must NOT call the parent method (opposite of a setting we have now).

Your thoughts accord with mine. I've been pushing that into future designs.

[AristosQueue (NI)]

It's time to decline this idea. It's been revisited a couple times, once during the design phase of OOP in LabVIEW NXG and again when working on interfaces for G, coming soon. a) There are too many problems with a class that cannot be instantiated, b) a decade worth of use of LV classes has shown little need for a class whose objects are never instantiated in dataflow, and c) abstract classes as they exist in LV today have show real value as transmission sentinels and error handling objects.

Therefore, we are declining the idea of true abstract classes (i.e. classes whose objects you will never ever see in a probe) in G.

[Darren]

Declined for reasons listed here: https://forums.ni.com/ni/board/message?board.id=labviewideas&message.id=41761#M41761