Re: avoiding huge globals files

Rudy Fernandes wrote: > > This is slightly off the subject, but bear with me. > > I have had extremely bad experiencies with globals, the problem basically > being tracing the history of values in a global during debugging. Globals are > great in 'set once, use many' instances like > > 1) RECORD LIKE table - when the program is INSERTing, etc into that table. > 2) INPUT ARRAY - because arrays cannot be RETURNed. > 3) REPORT screen variables - where much 'contamination' cannot occur. This is probably down to your coding standards. If programmers are not complying with coding standards, and using sloppy naming conventions, then problems will always arise. > but, for years now, I have been advocating avoiding globals wherever possible > for the following reasons > > 1) Tracking the changing value of local variables is infinitely easier. I don't see why. A variable is a variable, whether it is a global or local. Two areas cause problems: 1. Using global variables for more than one use. 2. Using local variables with the same names as globals. > 2) Reusability of a module which only uses local variables is hassle-free. Again, there is no difference here. With local variables, you have to: 1. Pass the correct parameters. 2. Return the correct parameters. 3. Use the returned parameters. With global variables, you have to: 1. Set the correct global variables. 2. Call the function. 3. Use the global variables. > 3) A common function RETURNing a local variable rather than seting a global > has a better 'handshake' with the caller. Again, I see no difference. The one advantage of globals over local variables is the fact that you always have to send the same number of parameters. With globals, if they are not going to be used on that call, then you don't have to set them. In terms of project coordination, I find it easier to pass on lists of required globals, rather than individual lists of expected function parameters. The requirements of both are still the same. > 4) Following the logic of a program in which functions use 'locals' is far > simpler. I suppose it depends on how it was written. ;-) > 5) Memory requirements of a program could be less. Aha! Yes, this is true. But remember that performance can suffer if all variable memory requrements are defined dynamically. But if you are short on memory, this can help. And you have obviosly never encountered the many memory 'leaks' available at no extra cost in 4GL. ( Errors like -4518 ;-) > My emphasis has been towards program maintainability and quality. I have not > considered SPEED at all. > > Does anybody have some inputs on the SPEED issue? Or any further thoughts on > Globals? Globals obviously take up more static space, so if memory is an issue, then passing parameters can help. But for performance, I would use globals. Globals also avoid errors like -4518. I'm not suggesting that all variables must be globals, or local. But when values are to be shared, globals will give better performance, and less headaches for maintenance. I have had to debug other peoples programs where they passed strings from one function to the next to the next, etc. They wanted to know why they were getting error -4518, I said I didn't know but use globals and it will go away. ;-) > In article <32A1EF90.7578@west.co.za>, > "Mark D. Stock" <marks@west.co.za> wrote: > - > >Casper Boden-Cummins wrote: > >> > >> Suppose I had a bunch of modules to be included in various programs. > >> Rather than create one huge globals file "hugeglob.4gl" and insert a > >> > >> globals "hugeglob.4gl" > >> > >> in each module, I could create a seperate globals file for each module. > >> This works even when globals with the same name exist in more than one > >> globals file. I can even define explicit duplicate globals in modules. > >> > >> Is this technique is safe? Is it the answer to huge globals files? > > > >You can create separate globals files for each module, or you can include > >the globals definition at the top of each module. Remember that the > >alternative syntax for the globals section is: > > > > GLOBALS > > DEFINE variable TYPE > > : > > END GLOBALS > > > >We use this method for our library functions which return values via > >globals. If a module is to call a library function, then it declares > >the appropriate globals at the top of the module. Obviously the data > >types must be the same. > > > >You can also direct globals at any module that contains a globals section. -- Mark. +-------------------------------------------------------------------------+ |Mark D. Stock - The West Solutions Group http://www.west.co.za | | The Informix FAQ is at http://www.iiug.org | |mailto:marks@west.co.za +------------------------------------------------+ |Tel: +27 11 803 2151 |If it doesn't work... force it! | |Fax: +27 11 803 2189 |If it breaks... it needed replacing anyway! | |Cell: +27 83 250 2325 |Well, that's how I code anyway! | +------------------------+------------------------------------------------+