Introducing the VI Definition aka "autoupdate from VI template"

[SteenSchmidt]

Hi,

I sometimes could've used a VIT that maintained its connection to the VI you create from it, in the sense that if you later update the VIT any VI created from it update equivalently. Here I suggest such a "linked VIT", I call it a VI Definition here (.vid?), but it could be named something else if you have a better term. I envision something like this:

Consider a VIT containing code like this (just a small stupid example, often VITs are more complex), except this is a VID:

Then you create a new VI from the VID, and fill in some additional code:

To illustrate which pieces of code comes from the VID, I've dimmed those parts (since they have a couple of special properties I'll explain in a moment):

What you may not do to the objects originating from the VID:

1) You may not delete or replace any of those objects.

2) You may not unwire any originally wired terminal.

3) You may not delete any existing cases from case structures, event structures etc. Special situations arise when a referenced typedef changes for instance.

4) You may not change any control labels (if the VID can identify the original controls by other means you could perhaps be allowed to change their labels?).

5) You may not insert any object onto an existing wire (if this can be done while maintaining the autoupdate functionality from VID to VI then it maybe should be allowed?).

What you may do:

a) You may resize any existing structures, as well as move any objects and wires.

b) You may wire to any originally unwired terminal.

c) You may insert any number of new objects.

d) You may add new cases to case structures etc, and you may reorder cases.

e) You may change structure labels and control captions.

f) What about original free labels?..

What the above makes possible is that if you later change* the VID all the VIs created from it will update as well (when they are loaded into memory and checks their changed .vid file). Only what was changed in the VID will propagate into the VIs, nothing else is changed including the custom code added to each.

You should be able to unlink a created VI from its VID, possibly with a password protection.

What do you think about this?

Cheers,

Steen

* When a VID is changed a lot it's probably not possible to detect 1:1 what was changed when LabVIEW later compares it with each instantiated VI, so some change history inside the VID should probably be maintained to enable LabVIEW scripting the same changes into each instantiated VI.

[Intaris]

Nice idea but the implementation is questionable to say the least.

What are the real-world use cases for this?

[SteenSchmidt]

Real world use cases include for instance a module template, which could have its external interface (which is part of the template) updated at a later point in time where you have implemented 50 modules already (happened to one of my customers the other day).

Sure you can get a long way with modularization, so it'll often suffice to update one or a couple of subVIs, but sometimes a template is the way to go. In this case there's currently no way to update the template code and make that affect the created copies. You're then in for a repeated manual fixup of those.

I agree that this suggestion is merely a fix for a non-optimal design decission at some point, but once in a while that was where the balance tipped.

/Steen

[SteenSchmidt]

Btw which parts of the implementation would you like to improve and how?

/Steen

[Intaris]

Seems to be very similar to an idea I posted a long time ago but phrased in such a way so that I was the only one who knew what I was asking for....

Personally, I see this needed when used in conjunction with accessor VIs for Classes a lot.  Trying to implement a framework and thena fter 80% of the work is done, realising that something needs to be changed.  BAM, a days work has just been scheduled.

[GregSands]

Kudo'd because I like the idea in principle, though I imagine there would be a few gotchas along the way.  I wonder if it would be easier for the VID to specify code regions that can/must be modified by a VI that uses the VID - those placeholders could look something like Diagram Disable structures.

[Daklu]

Interesting idea--it's like a dynamic template--but I'm not ready to kudo it just yet.

What you may not do to the objects originating from the VID:

Which of these 5 items are because you specifically want that restriction and which are because of perceived implementation problems?  (4 and 5 seem to be related to implementation issues.)

f) What about original free labels?..

Free labels don't affection the functionality and shouldn't be given the same protection as code.

You've explained what you can and can't do to the vis created from the .vid, but what changes do you expect to be able to do in the .vid that would propagate down to all the derived vis?

I agree that this suggestion is merely a fix for a non-optimal design decission at some point, but once in a while that was where the balance tipped.

This is the real sticking point for me.  I agree sometimes templates make more sense than reusable sub vis, but the functionality you're asking for (changing code in one place and having it affect all the callers) in the example can already be accomplished with a simple class.  Is it worth it to have R&D spend time adding an alternative implementation of a feature that already exists, especially when the new implementation is more problematic and more confusing than the existing implementation?

Is there some benefit to having this feature part of a template that isn't available with a class?  (Other than saving the cost of the dynamic dispatch call, which admittedly may be sufficient to justify it.)

[AristosQueue (NI)]

But, Daklu... you are one of the many who has asked for generic VIs and C++-esque template classes. Once we get into template specialization, what this idea is asking for isn't too far off that mark. Really, this idea is pretty much lambdas, with some odd syntactic idiosyncracies thrown in. With the lambdas, you might define the basic template VI, with the cut points for "before the for loop", "inside the for loop", and "after the for loop". It's not hard to imagine that in a graphical language like LabVIEW we could go further than the textual languages and have what might be viewed as an infinite number of cut points, i.e., code can be placed before, inside, after, around, in parallel, etc.

For those of you looking for use cases for this idea, I'd include the entire domain of functional programming under this rubric. The only difference is that in a dumb text language, you have no idea of the structure of the lambda that your functions are plugging into without reading exhaustive documentation. With the graphics, we would be able to show the graphical substitution and you could see how your plugged in pieces fit into the overall composite structure.

Interesting constant folding opportunities also arise if I can say "this same piece of code but with this constant applied to it", but which leaves open the option of the constant being specified as a fixed integer or as an array being connected to an autoindexing terminal.

.... not that I've given any thought to this idea myself or anything. 🙂

Kudos.

[SteenSchmidt]

@Daklu:

It is a dynamic template

Each of the 5 edits I outline as disallowed on a VI from a VID are to keep "magic" from happening when the original VID is later changed. a) I can imagine almost anything to be implemented, and b) what may and may not be allowed is just definition - so those two issues are not the limiters. I just expect it to be hard to understand (for the user) that something might happen to your VID-linked VI when you edit some part of the VID that you have deleted from the linked VI. It makes for some convoluted rules that must apply in such cases; imagine you have prim X in the VID, and delete that prim X from your linked VI. If you then in the VID replace prim X with its cousin prim Y, what should happen in the linked VI? If you kept prim X from being deleted from the linked VI the resulting change would be straightforward. It limits the possible use cases slightly, I agree, but most often you add to a template anyway.

Free labels... I agree that they should be editable/deletable. I was thinking that they might add some documentation that shouldn't be allowed to be removed, but that's just silly.

There are several existing ways to accomplish template-like behavior in LabVIEW; template-VIs, subVIs, typedefs and classes are just a few. My suggestion here is what I myself would have liked template VIs to be capable of. I don't find it confusing as long as the few rules I've outlined are adhered to. The only rule is basically if it exists in the VID, you can't remove it from the linked VI (unless you un-link the VI first). If the restrictions are fewer, the feature gets harder to understand. It should be as obvious as possible what you can and can't do, or else the feature won't be used. A prime example is the SEQ command on the HP4x line of graphical calculators, if anyone here knows that one (sort of a lambda/anonymous function for RPN). Immensely powerful but quite hard to understand and thus rarely used.

But as always, this is a big feature to implement, so should NI spend resources on this? If you judge by the kudo count probably not. That this feature is not in LabVIEW doesn't mean I can't do my applications.

/Steen

[AristosQueue (NI)]

> I was thinking that they might add some documentation that

> shouldn't be allowed to be removed, but that's just silly.

Possibly a label that says, "This code was generated from the template XYZ.vit" in order to explain why some items cannot be moved/deleted. Not sure how to indicate this, but I think it should be in there *somehow*, and a non-editable free label would be one mechanism.

> If you judge by the kudo count probably not.

And this is one reason why we don't judge by the kudos count all the time. Many of our biggest features have been ones that the majority of users could not see any use for when we first created them.

[Daklu]

But, Daklu... you are one of the many who has asked for generic VIs and C++-esque template classes.

Yep, I've asked for generics, but it's been 20+ years since I took C++.  I don't remember at all how C++ templates work, how much they differ from generics, or even if I learned them in the first place. 

Once we get into template specialization, what this idea is asking for isn't too far off that mark.

I had assumed the mechanism for setting a generic would be something like an option on a front panel control.  Are you imagining using vi templates for implementing generics?  How would that work?

Really, this idea is pretty much lambdas...

Except (I believe) lambdas can be defined at runtime.  This still requires everything to be defined at edit time doesn't it?

Each of the 5 edits I outline as disallowed on a VI from a VID are to keep "magic" from happening when the original VID is later changed.

Suppose you created something similar to your original vid example without the for loop, then built a bunch of derivative linked vis.  Then you realized you wanted the for loop, so you add it.  How should the linked vis react?  Should their custom code go in the loop or not?

I'm not opposed to the idea, I just think there's still a lot of room for unexpected behavior, and I believe that would make the applicable use cases for this functionality fairly narrow.   

Possibly a label that says, "This code was generated from the template XYZ.vit" in order to explain why some items cannot be moved/deleted. Not sure how to indicate this, but I think it should be in there *somehow*, and a non-editable free label would be one mechanism.

Ugh.  If you do this please give us some way to disable it.  An option in preferences, a super secret ini key, or maybe access to the scripting code that generates the linked vis.