Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Of Globals Summary: procedures are externals also Message-ID: <276@smds.UUCP> Date: 15 Dec 90 07:45:56 GMT References: <242@smds.UUCP> <252@smds.UUCP> <1189@ncis.tis.llnl.gov> Organization: SMDS Inc., Concord, MA Lines: 78 In article <1189@ncis.tis.llnl.gov>, turner@lance.tis.llnl.gov (Michael Turner) writes: [... retieration of artg's arguments against globals ...] > I've explained to many programmers my view that global variables are to > data structures what the GOTO is to control structures (worse, in many > ways, if you ask me--I'll use the occasional GOTO, but my references to > global variables tend to be to someone else's, not to any that I invented.) > A lot of people give me this response: that they only use them when > "necessary". When I go look at their code, there are always tons of > gratuitous global variables... > To me, the worst part of unconstrained use of global variables is the > uncertainty: when reading the code, you find yourself looking at something > that has no readily-available context or meaning; you don't know what is > going to change it and when. I respectfully disagree with these views. Procedures (which are also externals) have the same demerits. Consider the following code: procedure foo local x global FLAG ...... x = FLAG ...... x = bar() Do we know what FLAG is? No. Do we know what bar does? No. Both are externals supplied from outside the routine. In fact we might reasonably say that getting the value of the global, FLAG, at least does not have any side effects; no such guarantee is given for procedure calls in most languages. A blanket condemnation of "globals" is overly simplistic and fails, in my view, to grasp the nature of the problem. If we return to the widely condemned "goto" for an analogy we (should) ask: What is wrong with using "goto"s. The practical answer is not that the goto is sinful but rather that, in most cases, it is too primitive -- it does not reflect the actual flow logic being used. If one is going to discuss the merits and demerits of globals one should survey the uses that are made of them. Right off hand I can list some: (a) Environment (state) descriptors (b) Data transfer between subsystems (c) Private data with a subsystem I'm sure that others can come up with a much more extensive list. > Not only does variable-sharing "prevent a distributed program from being > reconfigured", I've found that it can prevent ANY significant program from > being reconfigured! It has probably prevented a great many programs from > being understood by anyone except the original programmer. Forget about > GOTO-phobia, how about "`extern' variables considered harmful? Color me a skeptic. The thing that keeps programs from being reconfigurable (to the extent that such a thing is desirable) is that they aren't designed with reconfigurability in mind. If that is one of the design objectives a set of globals which define the configuration can be a very useful thing indeed. Having said this, let me make a couple of points against globals. The first is that they disproportionately expand the name space of a program (as compared to procedures) since one can introduce more names with globals than with procedures for the same number of lines of code. The second point against globals is the lack of natural structuring. Let me use C as an example. In C all globals are in the same single flat name space. It is conventional to break this name space up using include files. However this conventional is easily defeated -- one can always go around the back door by using an "extern" declarations. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.