New Enum Class Primitive: "The Defined Enum" (with pictures)

[rcpacini]

(Resubmitted to include pictures)

Similar to the discussions on command and data cluster primitives, it seems many programmers would like the ability to have a primitive to move a message and some additional data easily. The current methods involve casting specific data types to generic types (i.e. Variants) which are then passed to sub-processes. Once in the sub-process, the process reverses and the data is cast back to the specific type. Many times this casting to and from generic data types not only takes time and resources but also requires managing many type def'ed controls for each specific data type used.

Here is a traditional method for passing data between processes:

Alternately, if the message (such as an enum) included the specific data type definition then no casting is required. This idea involves embedding inherancy of private class data into a defined LabVIEW primitive where each command/item is its own class of private data. It's like having your cake and eating it too! Or, it's like having your message and the data too! (cheesy, i know). Below is an idea for the configuration of the "Defined Enum":

Like a tab control, each tab is an Enum Item and the controls within the tab are specific controls associated with the item. The Defined Enum loads a drop-down selection list of the private data associated with the current item.

In the block diagram, like property nodes, the accessors would be used to get or set the values of the enum items. 

The sales pitch: When developing large applications where there are multiple services running in parallel it is often difficult to develop completely modular processes because the casting to and from specific data types require a control dependancy between the caller and the callee. Eliminating generic data casting would help develop a more robust hierarchy. I applogize if this idea is a repeat. Let me know what you think.

-Ryan

[AristosQueue (NI)]

What you ask for is called a LabVIEW class. Yes, really. With all the polymorphism that you're looking for.

And your solution to the communication problem of this data? Please check this out: https://decibel.ni.com/content/docs/DOC-17193

[AristosQueue (NI)]

I will say that I've been looking for images that make classes easier to view on the diagram, and I may borrow some of your approaches here for that purpose.

[MaryH]

Already implemented as LV class.

[rcpacini]

Hi Aristos,

Thanks for showing me the Actor Framework using classes, this was exactly what I was hoping for.

[JackDunaway]

Just wanted to add a quick comment to this thread: this idea is an important archive piece for the LabVIEW forums, because it demonstrates a common design challenge with great illustrations. People searching for a solution - yet lacking vocabulary such as "run-time polymorphism" ("dynamic dispatch") and "strictly typing" vs. "stringly typing" - might stumble upon this thread and discover LabVIEW Classes and LVOOP principles! So, +1 to rcpacini for the detailed write-up! 

[drjdpowell]

"User Events" are another method in LabVIEW that also allows the equivalient of strictly-types messages, in addition to LVOOP and the "Command Pattern".

[Wart]

It would be useful to attach a LVOOP implementation of the drawings to complete the loop.  You've then taken a common challenge with great visual documentation and turned it into classes that people are more likely to understand and appreciate.

[AristosQueue (NI)]

Wart: Excellent point. I do not have it as images, but I do have that "finish the loop" as video:

http://zone.ni.com/wv/app/doc/p/id/wv-3101

This web video shows the progression of how we go from a messaging scheme using an enum and variant pair to a class implementation and then into the Actor Framework for communications.

[Oligarlicky]

I think this idea has some advantages over OOP:

• Unlimited input and output tunnels
• It's easier to "sync" all the structures so they all have the same tunnels
• Direct writing to terminals and locals
• You can use front panel property nodes without wiring the references through

It also has some disadvantages but I think the advantages make is sufficiently different that the idea should not be "declined"