🚀 go-pugleaf

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.