Re: Globals In 4gl

John Leipold wrote: > > The subject of "global" and "modular" data definitions being used in > Informix 4gl code came up the other day. [SNIP] > 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. There are two sets of issues to consider. One is the PROPER way to design an application in a modular fashion. The other is to keep the limitations of your tools in mind. Towit: Global variables increase modular and functional cohesion, in effect acting as the glue that binds functions and modules together. The less glue the less tightly bound the various functions and modules are. You can more easily reuse code, maintenance is less painful, etc. On the other hand Informix 4GL uses a stack model for parameter passing and does not push pointers on to the stach but rather the data itself. Therefore experienced 4GL programmers tend to avoid passing too much as parameters, relying rather on module and global variables, because of the high cost of pushing and poping all of the data represented by all of those arguments. So the balance is between run-time speed and maintenance costs. Not an easy choice, but, few managers would agree to programs that were noticable slower just because they are easier and cheeper to maintain. Hence the, particularly unflattering and non-helpful, comments of the original developers. Art S. Kagel