LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP Interfaces

(Similar title here.  Different concept.)

 

Many OO languages provide an Interface construct that allows objects in unrelated class hierarchies to expose similar functionality that can be called via common methods.  For example, a Car class and a Race class might both implement a Start method.  Unless their common ancestor has a Start method (which may not be practical) there's no way for me to take advantage of dynamic dispatching.  Interfaces allow an object to temporarily disguise itself as a different object so I can use a single vi on multiple objects.

 

Using the Car/Race example, I would like to be able to create an IStartable interface construct that defines a Start method.  Car and Race, in implementing IStartable, create their own Start methods that will override IStartable.Start.  I could then transform the Car and Race objects into an IStartable type and wire that into IStartable.Start.  IStartable.Start would then automatically transform each object back into its original type and call its member Start vi.

 

A couple points:

  • Classes need to be able to implement multiple interfaces.
  • There needs to be a way for class designers to indicate which interfaces it implements.  Setting that up in the class property dialog box seems like the best solution.
  • There also needs to be a way for class designers to designate which member vis to use when overriding an Interface method.  I can't think of a good way to do this in the vi itself, so I'd also manage these settings in the class properties dialog.
  • The illustration uses a Type Cast prim even though the actual type is not being changed.  It would need a new prim.
  • I've toyed with the idea of hiding interfaces on the bd by having an 'Invoke Interface Method' node that would automatically do the transformation and call back into the class' overriding method, but I think that restricts developers too much.
17 Comments
Knight of NI

I guess this was never implemented...

 

D@~n!!  I need this now!

 

Kudos Darin... Wish I had found this earlier... 

______________________________________________________________________
Active Participant

Ray,

 

I do have an Interface Framework on the LAVA code repository you are free to download and use.  It's been a while since I've looked at that code but it might get you started in the right direction.

 

Dave

Knight of NI

I meant Kudos Daklu..

 

And thanks.  I will visit LAVA and have a look at it.

Hopefully, this will revive this thread and get more kudos.

______________________________________________________________________
Active Participant

I doubt this idea will ever get enough kudos to bubble up to the top of the list.  It's not something most LV programmers need.  We'll have to wait until someone in R&D champions the idea and pushes it through anyway.

 

Feel free to post a message on Lava if you have any questions on the framework.  (It wouldn't hurt to shoot me a PM too to make sure I see it.)  I'm interested in hearing of others experiences with using it.

Knight of NI

I have not gone that route, because I realized that creating a new object got me tangled into a spider's web Smiley Sad

 

I will visit the LAVA post in hope to figure out what I could have done (differently) and learn something along the way.

 

Thanks.

 

Smiley Happy

______________________________________________________________________
Member

I recently ran in this example.  I am building test code.  I have a Voltmeter class with read voltage as the only vi, and set it to required override.  Then I created a couple of voltmeters decended from it.  I did this so my top level code is very generic.  In the test loop I have the Original voltmeter class calling the parent read voltage vi.  Works very well.  Switched meters and created no extra code to handle it.

 

Seperatly I had code that needed an ammeter.  I have only one but I folloed that same pattern.  Created ammeter parent with one vi read current.  Then Created a child of it to impliment the actual ammeter I have in my hands.  I was liking how LVOOP was working out so far.

 

Then...I just got an aginlent multimeter and...now what.  I would like it to inherit from ammeter and voltmeter, heck maybe even ohmmeter.  I could not figure out an easy way to this in LVOOP.  This really killed my mojo.

 

James G

Active Participant

> Then...I just got an aginlent multimeter and...now what.

 

James, there are ways to deal with that situation without using interfaces.  I suggest you post the question over on Lava's OOP forum.  You'll likely get lots of responses there.

Active Participant

Incidentally, I encourage anyone liking this idea to go vote for Traits.  They are a better and more natural solution to the problem in Labview.

Active Participant shb
Active Participant

The interface implementation of the programming language Go also sounds intresting. A class is considered to implement an interface if all the required methods have been defined. The class does not (have to) mention the interface.

(Type System of Go in Wikipedia: http://en.wikipedia.org/wiki/Go_programming_language#Type_system)

Active Participant

Go's type system appears to be simulate duck typing in a static type system, and their Interfaces include elements of traits.  (The Interface can contain an implementation.)  Given NI's preference for a strong, static type system, I don't think that is a route they'd be willing to take.

 

(Though I admit to really wanting to build an app in a duck typed language.)