Re: avoiding huge globals files

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. 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. 2) Reusability of a module which only uses local variables is hassle-free. 3) A common function RETURNing a local variable rather than seting a global has a better 'handshake' with the caller. 4) Following the logic of a program in which functions use 'locals' is far simpler. 5) Memory requirements of a program could be less. 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? P.S. Usually, 'common' modules (which are used in multiple programs) never need to resort to using globals. CALL with parameters and RETURN information from them. 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. > >Hope that helps, ---------------------- Rudy Fernandes GIC, KUWAIT ----------------------