Re: [SPARK] Code safety and information hiding

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Robert A Duff wrote:
>> I don't agree that package-spec variables should be illegal.  Such a
>> rule accomplishes nothing, since the programmer can just have a getter
>> and a setter, which is just as evil.  In some rare cases, a package-spec
>> variable makes sense, and in those cases, the getter/setter method is no
>> better (just more verbose).
>
> Designs based around global (package spec) variables are clearly done
> by people who are not competent to be designing SW. 

I think I'll choose to take offense at this statement (it's 5:26 AM,
and I can't sleep because I've got a bit of the flu, so I claim the
right :).

I have an application called Goddard Dynamic Simulator (GDS); it is
used to test flight software and hardware for NASA Goddard (yes, I am
a rocket scientist). It has 90,000 lines of code, mostly Ada, some C
and VHDL.

The design uses information hiding, abstraction, etc; all the good
features of a good program, made easy by using Ada 2005.

However, there are some global variables. I thought long and hard
about each one, and decided they are the best solution to the problem.

One important global variable is the root of the symbol table. GDS
consists of many modules, that use the symbol table to communicate.
One module models a star tracker, another a spacecraft (which contains
the star tracker), another thrusters, etc. In addition, any symbol can
be written by the user, or displayed to the user.

This design has evolved thru several iterations of similar systems.
They all have a global symbol table.

In addition, there are global variables that indicate global
information about mode: 

   type Distribute_Mode_Type is (Master_Mode, Remote_Mode, Single_Mode);

   Distribute_Mode : Distribute_Mode_Type := Single_Mode;

this indicates whether GDS is running on a single computer, or on
several. This makes a difference in many places in the code.

   Ignore_Hardware_Errors : Boolean := False;
   --  Set True for unit tests when hardware is not present or should
   --  be ignored.

Unit tests are important, and this feature is the simplest way to
support running them without hardware, in a system that normally talks
to hardware.

   Main_Config : SAL.Config_Files.Configuration_Type;

More information that the entire system needs.


I claim to be competent to design SW; I have 20 years of experience,
and at least 10 monetary awards for outstanding performance, together
with high praise from my (internal) customers, to prove that. My
system has a few global variables because they are the right solution
to the problem.

> Such people can always find others ways to create SW that's just as
> bad. But such a person might not immediately think in terms of
> getter/setter operations if denied the use of global variables, so
> not allowing them might provide a little pressure towards better
> designs.

You have not said why getter/setter would be better for these
variables. I agree with Robert; they are just more verbose.

Hmm. You could try to impose control over what parts of the system are
"allowed" to write the variables, as opposed to reading them. But that
would require an elaborate system of IDs for various parts of the
system (which does not otherwise exist); definitely not worth it.

I'll make a counter claim; people who claim global variables are
_always_ bad should not be designing large complex systems; the
systems will be more complex than necessary, which is definitely a Bad
Thing.

> The real solution, recognizing that all SW people are not equal,
> doesn't seem likely to happen any time soon.

While it is true that all SW people are not equal, I don't see what
that has to do with the issue of global variables, nor do I see what
problem recognizing that might be a solution to.

-- 
-- Stephe