LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I add features to a LV class without interface?

Solved!
Go to solution

LV has no way to create interface AND has single inheritance.

 

So how the frack can I do this:

 

class Concrete : Abstract, IClonable, ISearchable, IWhatever

 

??

 

I read that you do interface like this:

  1. create a class
  2. all method are empty (no implementation) and have dynamic displatch terminals
  3. check the class -> Item settings -> "require descendant to override"

 

BUT this is just an abstract class (strictly speaking it is NOT, because LV doesn't prevent me to instantiate/use it. LV should set the broken arrow if I place an abstract class on diagram)

 

Obviously it work, but abstract (so to say) class is not an interface, it's more rigid.

 

Ultimately the situation is this:

 

either allow multiple inheritance (like C++) ---> NO

or allor single inheritance + interfaces (like C#, Java) ---> NO

 

so? what are the consequences?

 

I can't develop software without proper OOP, I can't port software from other languages

0 Kudos
Message 1 of 12
(3,362 Views)

Oh, boy. This isn't the first time this came up... Here we go again.

 


@Ironman_ wrote:

LV has no way to create interface AND has single inheritance.

 

So how the frack can I do this:

 

class Concrete : Abstract, IClonable, ISearchable, IWhatever


That is correct. You can't do that.

 

You  can use composition, in stead of inheritance. So Concrete has a IClonable, ISeachable and a IWhatever.

 

You can also use malleable VIs (>2017SP1). This only works during compile time (e.g. it will not dynamic dispatch on the malleable VIs). The malleable VI will adapt to the class (not object) wired to it, and it will automatically resolve the name of the class VI. So if put a "Clone" VI in it's diagram, it will adapt to each class wired to it that has a compatible Clone method.

 


@Ironman_ wrote: 

I read that you do interface like this:

  1. create a class
  2. all method are empty (no implementation) and have dynamic displatch terminals
  3. check the class -> Item settings -> "require descendant to override"

 

BUT this is just an abstract class (strictly speaking it is NOT, because LV doesn't prevent me to instantiate/use it. LV should set the broken arrow if I place an abstract class on diagram)


LabVIEW cannot break thinks if the abstract class is used. That would destroy polymorphism.

 

LabVIEW has no distinction between constants and controls in this aspect. So if instantiating the abstract interface is no allowed, how can we make a VI that accepts any child of the abstract interface? That would be a control of the abstract interface, and LabVIEW would break.

 

Also, an array of different children would polymorph to an array of their parent, the abstract interface. And if LabVIEW would break, it would be fairly useless.

 

It will be impossible to make anything decent if we could not instantiate an abstract class.

 


@Ironman_ wrote:

 Obviously it work, but abstract (so to say) class is not an interface, it's more rigid.

 

Ultimately the situation is this:

 

either allow multiple inheritance (like C++) ---> NO

or allor single inheritance + interfaces (like C#, Java) ---> NO

 

so? what are the consequences?


Consequence is we have to wait for it. Multiple inheritance will (and shouldn't) never be implemented. It gives as much problems as it solves, it will be hell to add to LabVIEW as most of those problems will surface during editing.

 

Interfaces might be there in the not to far future. There are some initiatives (like AZ Interface), but without native support I don't think  it will be optimal.

 


@Ironman_ wrote:

I can't develop software without proper OOP,


Well, I can Smiley Wink.

 


@Ironman_ wrote:

I can't develop software without proper OOP, I can't port software from other languages


Porting software from other languages will never be a one-to-one match.

 

I'd like to see interfaces (or rather traits), but I'm doing OK without them. Eventually, I think traits will be in native LabVIEW.

 

Containment goes a long way, haven't even used those malleable VI's (still in 2013, sigh). Of course there are situations where you'd like a class to be searchable, clonable or whateverable, but usually adding those methods (if needed, it violates single responsibility rule) works for now. Even without malleables.

 

Message 2 of 12
(3,336 Views)

Also from a completely non-LabVIEW point of view:

 

https://en.wikipedia.org/wiki/Composition_over_inheritance

 

0 Kudos
Message 3 of 12
(3,327 Views)

There are many different ways of OOP implementations.

 

Java is OOP and explicitly avoided implementing multiple inheritance because multiple inheritance is a very good and easy way to shoot in your own foot. 

 

The currently cool kid in the class, Python is OOP but doesn't even have dynamic dispatching, as does Lua too. 

 

C++ does support both multiple inheritance and dynamic dispatch but the multiple inheritance creates usually more often extra problems rather than solving any.

 

As to your claims that one can't write programs without having multiple inheritance and/or interfaces available, I have to agree with Wiebe fully: I can! Smiley Very Happy

 

Would it be handy if LabVIEW had real interfaces, or traits or whatever you want to call it? Sure! Necessary? Absolutely not!

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 12
(3,318 Views)

My question is not about composition/inheritance.

 

Interface is a type, I can have a method that takes(or returns) that type.

You can pass any object that implements that interface, even objects with totally different ancestors.

 

How can you do that with composition?

 

class Person : Human, IClonable {}

class Car : Vehicle, IClonable {}

 

I can now use IClonable anywhere I want, no patterns, no code breaks.

 

Any book says to use interfaces, because they don't lock you in.

Typically youi declare interface ---> declare an abstract class that implements ---> and now you do the concrete classes.

 

How can you do that with composition? I can't figure out.

 

class Person : Human

{

  IClonable c;  // ???

}

class Car : Vehicle

{

  IClonable c;  // ??

}

 

When you compose, you hide the interface inside the type, it's totally different.

I also read here that interface is implemented as abstract class with "force overide"-methods, but that is not what an interface does.

 

0 Kudos
Message 5 of 12
(3,304 Views)
Solution
Accepted by topic author Ironman_

Your question is "How can I add features to a LV class without interface?".

 

Well, the answer is with composition. Aka the decorator pattern. It will give an object access to the capabilities of the contained object, in other words: features are added without an interface.

 

As already mentioned (, by all of us, including yourself): abstract interfaces as well as traits, are not possible in LabVIEW.

 

Nobody said composition is a substitute for interfaces, but it is an alternative.

 


@Ironman_ wrote:

Any book says to use interfaces, because they don't lock you in.


Well, no book on LabVIEW ever said that...

 

Most OO books I've read suggest composition as an alternative for multiple inheritance.

 


@Ironman_ wrote:

Typically youi declare interface ---> declare an abstract class that implements ---> and now you do the concrete classes.


No, that's not what I typically do. I make concrete classes. When needed, I give the concrete class a parent, a child and\or a sibling.

 

AFAIK, Abstract interfaces where created in C++ to narrow down recompilation. When a module is compiled against an interface, the actual implementation can change, and the using module doesn't need recompilation. In LabVIEW, thinks are completely different.

 


@Ironman_ wrote:

How can you do that with composition? I can't figure out.

 

class Person : Human

{

  IClonable c;  // ???

}

class Car : Vehicle

{

  IClonable c;  // ??

}

 

When you compose, you hide the interface inside the type, it's totally different.


Yes, it is different. But it's a way to get IClonable capabilities inside Human and Vehicle.

 

Not sure what else to say. It is what it is: no (abstract) interfaces, some alternatives, try again in a few years.

Message 6 of 12
(3,293 Views)

@Ironman_ wrote:

 

I also read here that interface is implemented as abstract class with "force overide"-methods, but that is not what an interface does. 


Nobody said it is the same. But it is the closest thing to an interface you can currently do. You can keep complaining and demanding things from NI, but unless you are from a huge account that brings NI lots of money every year your complains will not really change anything, but annoy many people.

I'm sure NI is looking at this for a long time and has been considering the options many times already. But software development is about priorities and a stock market corporations strongest incentive is about earnings, so priorities will be determined accordingly. You can like that or not, but that are the facts.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 12
(3,282 Views)

There has been a big push from the LabVIEW Champions on this as well and it is looking like NI is in a position to start this effort.  I know nothing about timeline or implementation or etc.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 12
(3,279 Views)

Ok so the answer is :

 

Interfaces are implemented with Decorator pattern

 

it makes sense

thanks

0 Kudos
Message 9 of 12
(3,268 Views)

@crossrulz wrote:

There has been a big push from the LabVIEW Champions on this as well and it is looking like NI is in a position to start this effort.  I know nothing about timeline or implementation or etc.


AFAIK, It's still in kickoff phase. Knowing there is an intent to implement this is definitely exciting. I have full confidence that NI is (or will soon be) on the same page with us on this. Only things remaining are the details and the time line... 

 

This "lack of functionality" , I think aka "horizontal reuse", will probably be implemented as traits, not as interfaces (and I can guarantee not as multiple inheritance). This is not just a name difference, there are some fundamental problems that interfaces have, and traits avoid them.

0 Kudos
Message 10 of 12
(3,260 Views)