Introducing "Quick Classes" (an all-graphical way to define classes and anonymous functions all in one)

[AristosQueue]

This is an idea I've been working on for a while. It's time to let others start evaluating it. 🙂

 

 ^ I included the above for Dmitry Sagatelyan and similar folks who have asked me for these things over the years so they know the mindset to use when evaluating the idea. But it's written up below for LabVIEW users who only know LabVIEW as it stands today (Q3 2024).

 

 

 

 

 

 

Feedback and questions welcome. 

[James_McN]

I've used closures a lot in other languages and often wondered what they might look like in LabVIEW!

My worry with it as laid out is that there is a major conceptual break that the code on the diagram is executing in the subvi and as you point out makes for a weird debugging experience. And you still have to build a class, just on the diagram, not in the project. I'm not totally convinced that the benefit outweighs the cost there.

[Intaris]

I agree with James's point that it's a break in concept of the visual description of the Block Diagram.

In a sense, for me, it's similar to channel wires. These kind of break the typical dataflow scheme visually (even though they don't int hebackground) and as such, I feel that the loss of coherence on the visual side of the block diagram is more off-putting than the benefits they provide. Just my personal take.

With this, I feel something similar might be an issue, but this is for the purists out there, not people who just want to get something done.  But when I think back to when I finally properly grasped user events, I kind of had the same opinion then. The parts I'm interested in are the following: (bear in mind I'm not really familiar with closures)

Classes defined in this way cannot be inherited from, correct?

What happens if we use a class as an input for type which has, somewhere along the line, an ancestor class which can be loaded from disk? Does the VI just break upon loading if incompatibilities are found? Would this break the entire hierarchy or just the VI in question.... i.e. would such structure cases be treated as dynamic dispatch member VIs currently are in the IDE?

The part about NO ancestor having private data allowing this to work with classes..... I'm presuming there's no violation of encapsulation here, right? What's the difference between a child class not having access to parent private data and this structure? I'm not sure why the "no ancestors with private data" part is relevant.

Edit: Additional question: The local shift register: How does this interplay with the idea that the "quick object" (Instantiation of the "quick class") might be passed as a wire beyond the single node shown in the example? Does the shift register get passed along with it? Is this essentially private data?

Second edit: I originally attributed the first response to Wiebe, but it's James. Fixed, sorry.

[wiebe@CARYA]

All the following is just questions and exploration...

+1.

A quick class that isn't a .vim input:

The use case you show is an input to a .vim, which is a very specific case.

I just want to point out there are tons of simpler situations this would be very useful.

If I understand correctly, you'd would be able to make 1 VI that returns 1 (of N) custom 'quick class', for instance 1 of 10 "quick class' filters from a case, saving us 20 files (10 classes and 10 methods).

For a quick class as input to a .vim:

I suppose the structure would, after selecting the class's desired method, adapt to the specific method's connector pane, prototyped in the class?

The malleable would however accept any compatible connector pane as a valid method. When providing a 'normal' class, the method doesn't need to implement the exact connector pane.

Would the structure allow modifying the 'connector pane'?

If the quick class structure is defined in a .vim:

This allows a quick class to be defined with malleable code, generated at compile time.

This could be a great opportunity, because it would allow us to make top notch performing methods, defined at compile time.

If the recipient is a .vim too, there often wouldn't even be a need for dynamic dispatching when calling the method.

[wiebe@CARYA]

Concerning breaking the dataflow...

This would break dataflow, but not by that much.

A Vi call 'jumps' into the VI's diagram and back. Here it jumps into the diagram and back.

Of course this would be an advanced thing, definitely not a technique to use as a default solution.

[wiebe@CARYA]

Concerning debugging...

Debugging reentrant recursive dynamic dispatching (which is where all the fun is 😊) hierarchies, debugging is near impossible as it is.    

This idea might even make debugging easier, although that's hard to tell in advance to what extend it does (if at all).

[fefepeto_kb]

In general the idea is great provides an easy and quick way to implement complex hierarchies.

And this is the potential source of misuse. It is easy to do something not so great by using a feature like this as well. And this makes me ask the R&D to make sure to create thorough documentation around the topic with examples when it is beneficial, and when it should absolutely not be used. Unfortunately most of the developers are not researching the topic and its general use in other languages, just read the help (at best) and use the feature, improperly.