Add pattern matching to LV OOP

[PrimaryKey]

This is more of an object orientation thing rather than actor thing but would have huge implications for actor core VI, or Receive Message VI. Please add pattern matching into OO LV. It could look like a case structure adapting to a class hierarchy on case selector and doing the type casting to the specific class inside the case structure. You could have dynamic, class based behavior without creating dynamic dispatch VIs, and you would still keep everything type safe. https://docs.scala-lang.org/tour/pattern-matching.html

[drjdpowell]

Kudos, but this has been proposed multiple times over the years and not gotten implemented.  

[AristosQueue (NI)]

What jdpowell said, although VIMs and the type adaption for class methods seems to cover the vast majority of the adaptation requirements. Even more so when coupled with the Type Specialization structure, which allows you to specify arbitrary behavior per type.

Here's one of the submissions for a type structure:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Type-Structure/idi-p/3017975

I think this idea should be closed as a duplicate... please feel free to comment if you believe otherwise.

[drjdpowell]

---

What jdpowell said, although VIMs and the type adaption for class methods seems to cover the vast majority of the adaptation requirements. Even more so when coupled with the Type Specialization structure, which allows you to specify arbitrary behavior per type.

---

VIMs are edit-time adaption; this idea is about run-time adaption, specifically, an alternative to DD.  

[PrimaryKey]

Even C#, a purely OO language is getting pattern matching. 

Dynamic dispatch is less readable than a case structure, even with the diagram preview feature.

[AristosQueue (NI)]

Embedding a mini text language in the case structure seems really antithetical to LabVIEW -- I think it runs counter to our mission goals and the majority of our customer base. Can anyone propose a graphical+dataflow way to write this code?

[PrimaryKey]

AristosQueue, sure thing! There is an absolutely beautiful way to write this in a graphical way. You need to add to LV

1. an ability to create anonymous functions or more easily pass functions on a wire
2. with a capability to partially apply some arguments to those functions,
3. and pass that function as an input to the case structure.

I did a presentation about this on the European Architect Summit. I would be glad to have a chance to prototype this or explain the idea in more detail.

(Slide 33)

https://www.slideshare.net/slideshow/embed_code/key/p2gnZTc7C11Cg7

The function you would be creating would be the condition that needs to pass for a  case to evaluate, the missing input would be the case selector.

This way we get all the benefits and we do not even have to use OOP, so no bloated inheritance 🙂

[PrimaryKey]

In the approach above the case structure would need to have another input, for the function to be used as condition evaluator.

[AristosQueue (NI)]

I don't think that gets you pattern matching. Pattern matching is inherently textual matching in a format where we can prove orthogonality. An arbitrary function refnum doesn't do that unless it funnels down to a single ordinal output. It doesn't seem like that's any different than today's solution of two Case structures: the first is inside a VIM and produces an enum, the second selects based on the value of that enum (and uses any other outputs the VIM provides as the variables). It's still not pattern matching syntax.