Re: Using Global Variables

[haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.ed u!news.sei.cmu.edu!lph@ames.arc.nasa.gov (Larry Howard)]

In article <20600143@inmet>, shafer@inmet.inmet.com writes:
|> 
|> The use of global data is "really" just a case of efficiently implemented
|> parameter passing.  We could see this clearly if we just considered the
|> characterization of parameter passing in terms of its operational semantics,
|> insteaed of full blown descriptive prescriptions.   It's just the difference
|> between what is "really happening" and how we see fit to describe and map
|> it.  Optimization can then be viewed as part of compiling, not programming.

The use of global variables for communication between program elements has the
virtue of decoupling communication from invocation or synchronization.  This
type of communication can therefore be combined with a variety of coordination
mechanisms.  You have pointed out that global variables can be used to
implement parameter passing on subprogram and entry calls, and that this
decision could be made by a compiler in response to some global optimization.
It could likewise be made by a lead designer and embodied in an architecture.

There can be considerable safety in limiting a design to the
control/communication pairings supported by Ada in the form of subprogram
calls and rendezvous.  These are both predictable and understandable (;').
There may also be considerable power in other forms of coordination, even if
these same forms have been misused in the past.  I think we should only insist
that whatever is used be understandable and predictable.

I guess what I really objected to in this thread was the odor of orthodoxy
when (IMHO) we still seem to be on a fairly steep learning curve.



 Larry Howard  (lph@sei.cmu.edu)                       |
 Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis.
 Pittsburgh, PA 15213-3890   (412) 268-6397/5857 (fax) |