Re: Globals In 4gl

On 19 Jul 1998, Ron Delpiere-Smith wrote: > 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. True. > 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. True. > 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. True. I make extensive use of module variables which are private to the code in a given file. I try to avoid global variables whenever possible, but I4GL makes it difficult to avoid them completely. I will write small functions which can be used to access values stored inside a module by code outside (and inside!) the module. > Modular variables increase the amount of re-usable code dramatically. True. > 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. This is typically the main reason for having arrays defined as module or global variables. There isn't any other way of passing them around in I4GL. The other reason is that the records are big enough that the overhead of copying them onto the stack and copying them off again across each function call is too big for comfort. > 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. That can often work, but not always. It does not work if you have an INPUT ARRAY and/or a DISPLAY ARRAY and want to load the data in one function and process it in one or more other functions. > 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. Where this works, it is a good scheme. When it doesn't, you have to resort to global variables. Being a purist about globals is not going to get the code written and working, especially if there are arrays involved. > John Leipold <jleipold@msn.com> wrote: > > 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. One thing which neither John nor Ron mentioned is avoiding huge blunderbuss (or omnibus) globals files which define records (or, worse, arrays of records) for every table under the sun and which are used in every module and every program. These are horrendous. Since version 4.13/6.01, it has been possible to include multiple globals files in a single module. You should limit the visibility of global variables as much as possible, and this helps. DATABASE whatever GLOBALS "globals01.4gl" GLOBALS "globals23.4gl" -- Don't take the naming convention seriously! GLOBALS "globals46.4gl" -- Don't take the naming convention seriously! You will need to link the program with the object files for each of the globals files which are used, of course. The key problem with global variables is that there is no control over which code is accessing it (modifying it is the biggest problem). If your code is using GlobalVariableX for something and calls another function which uses it for a different purpose, you are going to have a hard time sorting out the conflict -- unless you decide not to use GlobalVariableX after all. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix -- see http://www.perl.com/CPAN