Convert Global Variable To Functional Global

[SteveChandler]

As a tool to refactor inherited code it would be nice if LabVIEW had the ability to convert global variables into functional global variables. I did a search and did not find this idea and will be surprised if it is not a duplicate.

You would pop up on the global and select "Convert To Functional Global". The vi includes error terminals in the standard locations but are (obviously) left unwired. The name of the FG vi would default to a concatenation of the name of the global vi and name of variable.

I will leave it up to the experts to come up with a better icon.

[SteveChandler]

I should be implied but I will add that this would replace all instances of the global.

[AristosQueue (NI)]

To what end? It doesn't buy you anything.

A functional global and a global VI have all the same performance* and race condition downsides as long as the functional global has a "get" and a "set" operation. The advantage of a functional global comes when it hides all the operations that are performed on the value inside of itself. If you're just doing "get" and "set", use a global VI. It's simpler to write. You can use a library to give it some scope limitations so it isn't truly universally global, but otherwise, it's what you should use.

* actually, the functional global will perform worse. It has higher overhead in that case.

[SteveChandler]

I would use the convert from global to functional global as the first step in refactoring code. The second step would be connecting the error wires. Maybe a better idea would be to convert from a global variable to a shared variable.

Maybe this could be done with the right click framework. Now I have an excuse to check it out

[SteveChandler]

You know what Aristos? You just enlightened me. Again! You have no idea how many times you have done that. It is awesome that NI has someone like you contributing to the forums and especially this one. You are a good 10% of the idea exchange's value! *

But this idea could be useful in a use case that I did not consider when I posted it. Suppose I have inherited a large application that uses a global variable all over the place. I decide that I need to do some kind of validation or logging. I could use this feature to convert to a functional global and add the extra code.

So if I could kudo my own post I would give this a half of a kudo. If I could give a post a half of a kudo

* 67.3% of all statistics are made up on the spot

[Mads]

It would buy you the opportunity to add functionality to the global (what those functions are is not possible for the feature to know so the get and set functions are just preliminary I would say). Kudos for suggesting a way to simplify a relatively common task. There are lots of features that we can implement ourselves now with scripting, but which would be nicer if they came out of the box.

[AristosQueue (NI)]

> It would buy you the opportunity to add functionality to the global

My point is that you only buy value if you *eliminate* the get and set and only have other operations. Converting globals directly doesn't buy you anything good. It only slows down your code. I would expect that if we had such a simple replace tool that people would think there was value in doing that substitution and would do it willy nilly. Does that make sense?

[RavensFan]

I would argue that converting globals to functional globals is not a particularly common task to make it worth the effor to develop a tool to change them.  If you are starting a new project, you are going to start using functional globals right away and skip the globals entirely.  The only time you would do the conversion would be if you are trying to rewrite old code where the original programmer used globals because that is all they knew or believed was best.  How often do you really wind up rewriting old code?  When you do, you are probably spending much more time fixing other problems with the code, and are probably rearchitecting the whole application anyway.  Converting globals to FGV's manually is probably not costing you that much time in the big scheme of things.  And as AQ has said, you probably need to do a lot more work to the new FGV anyway to make it worth the changeover.

[SteveChandler]

Ravens Fan, you are right. I have a situation now where this would be helpful. I am replacing a BUNCH of global variables in some inherited code into functional globals. When this is done I am going to test it then add logging. It would be nice if LabVIEW could do the tedious part but this is something I probably will not have to do ever again. This is one of those things that would be very useful but the usefullness is rare. Kind of like having a pickup truck. It would sure come in handy about twice a year but that doesn't justify the cost of buying one. I will just rent a U-Haul if I need to move a couch. If I moved couches every day that would be different.

Aristos's comments made me re-think how I am going to do this. I will keep the global but wrap it in a subvi. I never considered using a global variable instead of a shift register in an action engine

Besides I have been meaning to check out scripting in some more depth. Maybe as a fun project I will try to make a plugin for the Right-CLick Framework that implements this idea.

[DFGray]

Wrapping the global in a subVI cannot prevent it being called elsewhere, leading to issues if you are ever planning on handing this code to someone else.  If you truly need global data structures, data value references and LV2 global action engines are your best bet (single-element queues, if you want the speed of data value references with names).

[SteveChandler]

Wrapping the global in a subVI cannot prevent it being called elsewhere, leading to issues if you are ever planning on handing this code to someone else.

I will create a library with public vis to access the privately scoped global so I am not worried about that.