Re: avoiding huge globals files

Great! I was looking for a discussion on globals with somebody who actually advocates them (rather than use them by accident), and it looks like I've got one. Before I expand my point of view, let me provide a point of reference. We run an insurance application with about 700,000 LOC in about 1000 4gls. Our 'important' 4gi objects (the ones we usually spend time with) have a typical configuration as follows (average of 8):- - 15,000 LOC in about 20 4gls - half of these 4gls are library 4gls - about 200 functions exist (about half in library 4gls) - about 800 CALLs are made (about 75% to library functions) In article <32B01B83.395D@west.co.za>, "Mark D. Stock" <marks@west.co.za> wrote: >> 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. If you can manage to enforce a single use for a global variable, you either have angels working for you or a very big stick. Still, one would need to spend a significant effort in 'variables management'. Take our case above. Assuming our library functions have 3 parameters each and return 2 variables, we would need to be managing 500 global variables. Additionally, monitoring 'single use' isn't exactly a trivial task. Also, if a library function is called more than once in a 4gi (as is usual), the globals concerned are actually being reused (in a sense different from what we've been meaning so far) and one is open to possible inconsistencies (calling without setting, typically - but I can think of others) With locals, as they exist only in the function in which they are defined, it is simple to track changing values. If they have been passed, the backward path is very clearly defined. >> 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. > Let's examine this further. Let's say I want to use a library function NOT PREVIOUSLY IN USE in my 4gi. If the function used globals, I would need to do the following 1. Define the globals in the calling 4gl (copy and paste from library) 2. If the global definition already exists (how creative can naming be?), change the variable name in either my 4gi or (ouch!) in the library AND RIPPLE THROUGH all other 4gls. 3. Set the globals (using variables existing in caller) 4. Call the function 5. Use the globals (possibly setting variables to them) 6. If I've added the globals to a 'global.4gl', re-compile all other 4gls using it. If the function used locals, I would do this 1. Copy & paste the library function FUNCTION stmt into the caller 2. Change the parameter list to reflect the variables already in existence within the caller 3. Add a RETURNING statement using variables (usually already in existence in the caller). There are some obvious differences, but don't forget the LOC saved. LOC may seem trivial, but using my example above, there are actually going to be upto 600 * 5 = 3000 less LOC (that's 20% of code, guys) >> 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. Funny, here was I thinking that the fact that you had to send a specific set of parameters was an advantage in favour of 'locals'. I see this 'restriction' as a built-in check (runtime & sometimes, compile-time) to ensure that the function has all the required info. to do its job. I would be a little suspicious of a function which uses a varying number of variables (probably doing too many things and needs to be simplified into multiple functions), but you could alwayes pass nulls. There is no such check for a function using global variables. I could happily call a function without setting the globals or worse, setting the wrong ones. Here is an analogy to show the 'handshake'. Local call : I call the Mailman (called function) and hand over a letter and money (params) to him. When he returns, he hands over to me the postoffice receipt. Global call : I place a letter lying on my car seat and money in the glove compartment. Then, I call the Mailman on the phone and say to him 'Do it'. When he returns, he places the receipt in the car. Sure, both can work, but there's nothing to beat the face-to-face contact. >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. All our library functions are read-only. We are experts at copy-and-paste (vi registers) which is effectively all one needs to do to use a library function (see above). And there is one simple rule (this is a global) - Use library functions wherever possible. The second rule is - if there is no library function, use locals anyway - the reason, it automatically is a candidate for the library. >> 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. Just to clarify it in my mind, do you mean the following? Local variables come alive only when the function is called, and die at the end of the call. Memory has to be allocated and then deallocated and that will take CPU cycles and time. Globals may use more memory, but after the initial allocation, there aren't any allocation/deallocation overheads. Makes sense. Thanks. > >And you have obviosly never encountered the many memory 'leaks' available >at no extra cost in 4GL. ( Errors like -4518 ;-) Nope, not with 4.1. Regards ---------------------- Rudy Fernandes GIC, Kuwait ----------------------