LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

LV2017: The Future is Malleable

10/9/2017

5 Comments

 
Ethan Stern
Picture
If you haven't already heard--or tried it for yourself--LabVIEW 2017 offers a simple but powerful new language feature that definitely warrants a deeper look.

Somehow, I made it all the way to the CLA Summit in Austin--having used LabVIEW 2017 for months--before learning about this. Obviously I neglected to scan the LabVIEW 2017 Features and Changes list. At the very least, this new feature addresses the common tedium of making typed polymorphic APIs. It also potentially addresses a design problem I've been banging my head on for months. (A little more on that later.)

What is a Malleable VI?

For starters, check out the link above to the LabVIEW 2017 new features page. It covers the basics of Malleable VIs quite thoroughly. It turns out, that the strict typing of data wires in LabVIEW, and the abundant polymorphism in the IDE, permit the compiler to make some pretty powerful (i.e. time-saving) assumptions. Let's consider a simple scenario:
  • Wire two DBL numbers to an add node
  • Highlight the add node and select Edit --> Create SubVI
  • The scripted subVI now has two DBL input terminals
  • Save the new subVI to disk
...But perhaps we change the source data type later and our calling block diagram now uses integers instead of DBLs. We'll see coercion dots on the subVI's inputs. If we want them to go away, we must either cast the integers to DBLs upstream of the subVI or change the subVI's input terminals to the new integer type.

The thing I never wondered until learning about malleable VIs is, why?
  • The input tunnels are conduits for data and they establish an expectation--we could say an interface to the outside world.
  • HOWEVER, the add node--the only source code inside the example subVI--is polymorphic
If everything inside the subVI is polymorphic and can easily handle a different numeric type, why impose this unnecessary rigidity on its connector pane? Now, we don't have to.

Make a Malleable VI

In case you were too busy to read the LabVIEW 2017 features and changes list linked above, here is a comprehensive list of instructions for converting a standard VI to a malleable VI:
  1. Change the ".vi" file extension to ".vim"
Voila! Your subVI now defines a malleable (i.e. flexible, adaptable, less rigid, quasi-polymorphic) interface for its caller. Wire something in. If that something works, everyone (and the compiler) is happy.

In my world these attributes are more often helpful than harmful. Is it good that LabVIEW doesn't treat every VI as malleable? Sure. On the flip side, the behavior exists if you want it, and with only the tiniest effort. Edit-time polymorphism now traverses VI boundaries!
Picture
What's the performance penalty for this compiler sorcery? As far as I can tell, absolutely none--and this makes complete sense. There should be no performance difference at run-time. The malleable VI is still called statically (in fact, it is inlined) and the compiler checks and adapts type(s) at edit-time. If you did something silly, like try to add strings inside a malleable math VI, you'll get a broken wire.

Goodbye (Most) POLY VIs

This all felt immediately relevant to me because I just recently spun my own polymorphic array functions (in LabVIEW 2015) for Promote and Demote element. I figured I would do it right and make both functions polymorphic so I could reuse these simple widgets in other projects. After a bunch of tedious tinkering, typing, and testing, I had two polymorphic selector VIs, 26 typed instance VIs, and one big annoying compromise--properly handle only my most common data types.

Polymorphic selector VI for Promote Element​:
Picture
And the disk footprint for both functions:
Picture
With malleable VIs, there is no polymorphic selector VI, and the footprint shrinks to:
Picture
Not only is this far easier to write, maintain, and test--it also handles types I chose not to support because I needed to draw the line somewhere. (I originally added that dirty polymorphic variant instance to handle the types I wasn't willing to code explicitly.)

In this slick new world, the only thing that matters is whether the input types play nicely with the subVIs and primitives inside the malleable VI. All array element types work just fine, and I only wrote one VI for each behavior (Promote, Demote). ​Ladies and gentlemen, I think we have a winner.

But surely this requires some new syntax, terminal type, or something?
​NOPE:
Picture
I made my VI icon background orange because that's NI's convention with the new malleable VIs added to the palettes. It was simply a style choice.
Picture
I used variants for my malleable array type because they imply "wire anything!" It actually doesn't matter--I could have used input/output arrays of DBL, I32, String, etc.. Setting the VI as malleable tells the compiler to reconcile types at edit time--and it does!

The Future, Service Pack 1

At the CLA Summit, we got a quick preview of the malleable VI behavior coming in LV2017 Service Pack 1, and that's when I got really jazzed. SP1 malleable VIs will include a form of dynamic dispatch that allows classes to implement non-ancestor methods. GET OUT.

For months, I have worked on a home-cooked solution to object-oriented interfaces (the capital "I" interfaces that exist in other languages). After lots of deep thinking, kludgy demo code, and wheel-spinning, I had no good solution that provided clean, composition-based, functionality (probably because it was impossible). No harm in thinking big.

...But combine malleability with object-oriented dynamic dispatch (i.e. run-time polymorphism) and you suddenly have a powerful non-hierarchical way of designing classes. If I'm thrilled with the prospect of (almost) never again writing a polymorphic VI, I'm borderline giddy over this interface possibility. I can hardly wait to try some cleaner (and 100% kludge-free) design patterns with the release of LV2017 SP1. Stay tuned.

Ethan Stern is a Managing Partner at Composed Systems and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, NI Certified Professional Instructor, and a certifiable LabVIEW geek.
5 Comments
Adam V. Steele link
2/19/2018 08:07:29 pm

Any thoughts now that SP1 is out? I was giving some thought to whether this new .vim functionality could be used with the actor framework, to make use of composition there. I couldn't see how to make it work.

Reply
Ethan Stern link
7/3/2018 06:44:21 pm

Yes, many! I finally tested how close I could get to a legitimate interface with 2017 SP1 (tantalizingly close). I think the best use case for malleability right now (for my stuff, at least) is making an API that spans branches of class inheritance. Might make a good blog post...

Reply
Felipe
6/23/2018 05:48:38 pm

Hi Ethan,
Any news on this dynamic dispatch malleable VI for OOP?
Regards.

Reply
Ethan Stern link
7/3/2018 06:45:18 pm

Yeah, look for another post sometime soon!

Reply
kosist link
7/31/2018 04:34:49 pm

Let me share then also my post regarding malleable VIs usage for classes - http://kosist.org/2018/07/malleable-vis-class-adaptation-or-how-to-create-universal-class-data-accessor/. I played a bit with its usage for class data accessors, b/c it also seems a nice way to reuse the code then... I'll be very happy to hear any feedback about it )))

Reply



Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources