Re: avoiding huge globals files

Rudy Fernandes wrote: > > 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. Well, that's very forward of you. But hey, it's raining, nothing on TV and the phone lines crackle wouldn't support a conversation between frying bacon, let alone humans, let alone a 14400 modem. So, a typical evening in Africa. ;-) So, carry on..... > 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) What does it do,... run the world??? Gees, let me guess, it's one of those applications that 'EVOLVED', from about 4BC, or 1986 if memory serves me. > 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'. I haven't noticed any wings, but my stick IS quite large. ;-) > 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. It depends on the parameters. If each function is passed, say, a user name, then a single global would manage this. > Additionally, monitoring 'single use' isn't exactly a trivial task. Of course. Life's tough as well. Also, single use isn't always necessary if it is really managed. > 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) Of course variables get re-used. This has always been the idea. They are not just areas of memory to be allocated for one-off usage, then thrown away. Local variables have their place, and form the majority, if I were to guess, of a program's variable count, but the benefit of a global is that it is defined once, memory is allocated once, then you can use it as often as you like. I am beginning to get the idea you don't respect your programmers. If not, then get new ones. :-) > 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. If you are tracking variable values within a function, globals will change exactly the same as locals. I don't understand this argument. If you mean that globals can be changed by CALLs from your function, then yes. But as you say, this requires management the same as any other area of the code. This ability, of another function to directly change the globals being used by your function is one of the benefits, not a curse. This is were the performance issue comes in. It is a large overhead on memory management to pass the same variables to each function in a long list of nested CALLs, then pass them back again right up the chain. If you simply wanted these functions to act upon a set of values, then they could all act upon a single set of globals instead of accumulating a set of local variables for each call. Think of the memory saving, and the speed. ;-) > >> 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). Very cute. You had me laughing for, ooh......, seconds. :-) If that's the way you want to code, then why are we even having this discussion? If you already have the variables defined, then go ahead. The only reason I get involved in these type of discussions, is because I program Informix 4GL for performance. People NEVER ask me to come in and help them make their application use less memory. But I DO get lots of requests to come in and make it go FASTER. In a well thought out application design (what do you mean "what's that?"), you will have a handful (okay, I have big hands) of globals that get used by some, if not all modules. And yes, if I am asked to hac.., er modify an application, and I consider conversion of a few parameters to globals will increase performance, then I will go through the steps you suggest. > 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) Now don't get silly, you need MORE lines of code for local variable definitions. > >> 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,@@N