Anonymous Method Structure

[smoores]

The ability to define anonymous methods to be called multiple times within a block diagram.

[AristosQueue (NI)]

Another favorite brainstorm topic of mine.

I have several drawings around that look vaguely like that.

I don't know why you have those "10"s wired or the orange wire coming out of the structure... pretty much defeats the purpose... but otherwise, yes, I like the idea. Wish I had the spare bandwidth to chase it more.

[AristosQueue (NI)]

My diagrams tend to look more like this:

I have many variations on this theme.

[AristosQueue (NI)]

For example -- let's make that "define connector pane" input optional. It's sometimes useful, but not always. So...

When you drop a Anonymous VI structure on the diagram, let's create one on the front panel also. Any control you add inside the rectangle on the FP puts its FPTerminal inside the structure on the block diagram (and cannot move out). The structure on the panel has a small rect where you can connect terminals to the local conpane. Now you don't need a separate input to define the type AND we have a definition for the anonymous VI's front panel, which will help with debugging.

What do we do for a panel if you do wire that "define connector pane" input? Well, LV can autogenerate one -- default control for each type.

[AristosQueue (NI)]

Note that if you put the Anonymous VI structure inside a loop, you get a different refnum every time you call it -- each one closed over a potentially different value of Numeric. It's essentially a reentrant clone with an injected value -- there's a constant in its compiled code that is varied for each clone.

You want some really fun brainstorms? Draw a channel wire crossing that Anonymous VI structure boundary and ask yourself if that's meaningful. Hint: it isn't meaningful as channels are defined today, but the places it'll lead you in terms of async communication models and models we might use for them are intriguing.

[GregSands]

So basically, create a sub-VI without creating a separate sub-VI.  Took me a while to work out that was what was meant!

In response to AQ, I do like the idea of defining controls, but I don't think it should be on the main VI FP.  As an alternate suggestion, controls could be embedded into the AnonVI border in the BD, and the connector pane could be in the top-right corner of the structure, with the same functionality as a normal ConPane but applying to the embedded controls/indicators.  If a FP is needed for debugging, then that can be defined separately.

If that's not possible, then I'd prefer a pop-up FP with connector pane, and pretty much no other menus or icons, and not to use the main VI FP.

This idea has a lot of overlap with an idea I suggested way back, which I thought was pretty good 🙂

[AristosQueue (NI)]

> So basically, create a sub-VI without creating a separate sub-VI.

That's the minor aspect. Sure, it's nice to create a VI no one else can call and eliminate a file from disk. But the big gain is the closing over run-time values and the performance gain thereof.

[AristosQueue (NI)]

> This idea has a lot of overlap with an idea I suggested way back, which

> I thought was pretty good 🙂

Please see my new comment on that idea. (Avoiding further comment here to avoid hijacking this thread.)

[oskretc]

Nice try JavaScript... 😉

I do  see the benefit, and I use it a lot in node is, just in the context of a subvi I don't see how it will improve readability. Perhaps in a top VI with a case structure executing same code, but what stops you making a subvi.

[AristosQueue (NI)]

oskretc the closing over caller values cannot be done with a subVI. At best you can put a control on the front panel, NOT connect that control to the connector pane, and then on the caller diagram, create a new reentrant clone and then set the value of that control on the panel. Terrible performance, complex code, and very error prone.

(Note you may have missed -- the call to the anonymous function is typically not on the same block diagram as the declaration of the anonymous function. It is typically passed into a subroutine and called several layers deep within a framework. Different callers of the framework would instantiate entirely different VIs and use different closure values for every call to the framework.)

[AristosQueue (NI)]

PS: Not sure what the reference to JavaScript is about. This can all be done strongly typed, unlike JS.