Re: Globals In 4gl

These are all good points below, although I'm pretty sure that modular variables also "grab memory when the program is started and hold on to it until the program ends". Another point would be recursive routines which are only practically handled by function defined variables. If a user is editing a particular customer record, for example, and the application allows him to "travel" to other tasks, he could end up traveling to another customer record. You now would have the same function active twice (two open forms) for two distinct customers. If the record variables are global or modular then the functions will overwrite each other. For this reason and the reasons already mentioned below I use the following strategy: 1. Define variables in functions whenever possible and not too impractical. 2. Define modular variables for values that need to be used even after the function that set them ends. In other words use them instead of globals. 3. Define globals only for very few truly system wide variables that are unlikely to change in any way. The application I'm currently involved with has over 300 modules (250 thousand lines of code) and growing. There is one globals file with 8 variables. If all my modular variables were globals this would be a maintenance nightmare. As a side note, 4J's version of 4gl, now to be adopted by Informix as Dynamic-4gl, supposedly has some extensions to variable and function definitions. If I remember right, you can make functions "internal" so that they are only seen by the module they are in, and you can make modular variables "external" so that they can be referenced by other modules, just like globals, by "module_name.variable_name". Enough for now, ---------------------------------------------------------------------- John H. Frantz Power-4gl: Extending Informix-4gl john@rl.is http://www.rl.is/~john/pow4gl.html Ron Delpiere-Smith wrote: > > John: > > A couple of things to bring up to their attention: > > Globals grab the memory when the program is started and hold on to it until > the program ends. > > Global variables require the constant recompiling of all modules that make > use of the globals file when any changes ate made to the file. It the > globals file defines records using the like syntax, you have to compile > everything if you alter a table that is referenced in the globals file. > > Modular variables allow for the re-use of code and removes the > interdependency between all the modules. It is true that there is more > coding involved when using strictly modular variables. however, this > additional coding will pay off when you need to do something that works > just like that other program. > > Modular variables increase the amount of re-usable code dramatically. > > I do not agree with you wanting to define arrays in globals (for reasons > stated above). I know that you cannot pass arrays in function calls. But, > do you really need to pass the entire array? Why not write the function to > deal with one record and call it multiple times in a loop if really needed. > Define the array in a controlling function and pass the elements to called > functions. This method makes it easier to change the number of elements, > all of them are in one function. When the function has completed, the > memory is released, or at least made available for re-use else where in the > program. > > -- > Ron Delpiere-Smith > System and Database Administrator > Sloan Valve Company > > (remove the "nospam_" from the email address) > > John Leipold <jleipold@msn.com> wrote in article > <uZ8Q7vzs9GA.211@upnetnews03>... > > The subject of "global" and "modular" data definitions being used in > > Informix 4gl code came up the other day. > > > > The system I am currently working on uses globals as the defacto standard > to > > pass data from module to module / program to program. Most of the 4gi > > programs use 15 to 20 complete global record definitions (DEFINE g_record > > LIKE record.*) and a plethora of modular variables for lot's of different > > things. > > The use of variables with modular modular scope was also being discussed. > > Their use in this particular system is worse than the use of abuse of > > "globals" in the system. > > > > All of my experience prior to this contract has lead me to believe that > the > > fewer globals used the better. I felt that descrete functions without > global > > impact was the best design methodology. I pretty much have take this as > > gospel and never strayed from the "true" path of functions with > parameters > > passed in and results returned. > > > > But other than "I've always done it that way" I don't have many specific > > arguments against using massive global files. > > > > I think that arrays most certainly need to be global in scope and certain > > variables are okay for modular scope (especially if these variables gain > > dramatic performance increases in code) > > > > Of course I was slapped down pretty hard by the employees that created > this > > system and was told I didn't know what I was talking about. > > > > Any thoughts, one way or the other would be greatly appreciated. > > > > Thanks.... > > John Leipold > > Access Data Consulting Corp.