LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
WG-

GOOP - Need a new kind of "variant" for inherited functions

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

Currently I'm busy with GOOP and I came across the following problem. 

 

I have a validator class. The purpose of this class is to validate data. The validator class as a number of childrens...

 

Validate IP address

Validate string length

Validate inRange number

Validate Alpha

 

The main, validator, class has a function called "valid?" This function has 3 inputs and 3 outputs

 

Inputs:

- Object

- The data that must be validated

- Error

 

Output:

- Object

- Valid?

- Error

 

The children classes must inherit this function and overwrite it. Now the problem is is that each of the above validators have a different datatype which must be validated....

 

Validate IP address has a string as input

Validate string length has a string as input

Validate inRange number has a number as input

Validate Alpha has a string as input

 

Now you might see the problem. To get the children to inherit the function from the main, validator, class the connector pane must be the same as of the datatypes... This means that I have to choose in my main function to use a string or a number as input... This is something that I don't want... I want to be able to select a datatype called "yet unknown datatype" in my main "valid?" function in the main, validator, class. So that I can use any datatype input in my children that is suitable for that implementation. 

 

 

My idea is thus to create a new kind of datatype which sort of represents "any kind of datatype known to labview" which can be used in functions of a main class that are inherited by its children, which are all using a different input datatype.

 

ps. Now you could maybe suggest why not use a variant datatype? Yes this is possible but the problem is;

- I would have to cast the data back

- It isn't very neat programming, the variant solution is in my opinion more a kind of hack to make the code work.

 

pss. Yes but if you would do this... then...

- Yes there are proberbly a few more work arounds thinkable, such as creating two "Valid" VI's one inherited (Valid?), one unique of the child (_Valid?), but these are in my opinion still workarounds and do not really provide the functionality that is needed. Which is pretty common in OOP languages.

 

psss. if anyone knows a better title for this described idea let me know it! 

6 Comments
tst
Knight of NI Knight of NI
Knight of NI

Here a couple of relevant answers:

 

1. Make your types LVOOP types. Yes, that sucks.

2. Vote for this idea.

3. Read this.


___________________
Try to take over the world!
WG-
Member
Member

Thanks for both your linkes tst. But a question about your first item. What do you mean exactly with LVOOP types? Can you give a link with some explanation about this? I only just started with GOOP but have experience with OOP languages. This was actually my first GOOP class but I immediately got stuck with this problem (Maybe I should rather call it a limitation of the LabVIEW programming).

tst
Knight of NI Knight of NI
Knight of NI

I don't know if you're using LVOOP or not. LVOOP is the built-in OOP, available since 8.2, which supports encapsulation and inheritance. You can define an "IP adress" class or a "string" class and then have the data type of the input terminal be LV Object. Since all LV classes inherit from that class, you'll be able to wire it in.

 

The main problem with this is that you have to create all these classes and that today they are unusable with the LV primitives - you will not be able to wire the string class into the String Subset primitive, which is why I said it sucks - you need to build anything that can interact with the class.

 

There's all kinds of content available on LVOOP and I suggest you look for some tutorials and read through the LV help. Here is one relatively advanced document. There are more links at the bottom of it.


___________________
Try to take over the world!
WG-
Member
Member

Ah ok I think I understand what you mean. First, yes I'm using LVOOP. Second what you mean is that you just create a class for each input, string, numeric, array, etc... and because you have a parent class called "datatype" for example you will be able to use that class as a input of my validation class.which can then be used by the children.

 

Well yes this is a workaround to but still... a workaround 😞

tst
Knight of NI Knight of NI
Knight of NI

> Well yes this is a workaround to but still... a workaround

 

Not necessarily just a workaround. My understanding is that in an OOP language it can be advantageous to have all data types as classes and that this is basically what Java and the .NET languages have. Today, this is impractical in LV (although not impossible), but it's certainly possible that in the future LV will develop LVOOP to such a degree that it will even migrate all the native types to it.


___________________
Try to take over the world!
Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.