Re: [SPARK] Code safety and information hiding

["Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org>]

Stephen Leake wrote:
> 
> In this case, it's anyone vaguely associated with launching rockets,
> or working for NASA. It's intended as an assertion of authority,
> hoping to instill fear and obediance in the audience.

I guess I'm a rocket scientist, too, then. I've been involved with SW 
for space systems.

> Good point. But "rocket scientists" are actually typically engineers.
> The original term was for the people who made the first large rockets
> actually fly; they were certainly engineers.

Precision in language for technical subjects is a Good Thing.

> In my system, as you alluded to above, the use of each global variable
> is well documented; programmers are expected to follow the rules in
> the documentation. 

It sounds as if we're in general agreement.

> Of course, every time I add a new programmer to the team, they
> discover new ways to (mis-)use the globals that were not covered by
> the documentation :).

Of course. If the global variables weren't there, they'd be stymied.

> That would be essentially a globally visible getter/setter; the getter
> must be globally visible, but the environment task which calls the
> setter should not be. I don't see any way to enforce the rule of which
> task is allowed to set the variable at run time.

There would be no setter. You'd have something like

package Mode_Handler is
    type Mode_ID is (...);

    function Current_Mode return Mode;
end Mode_Handler;

The body of Mode_Handler is responsible for maintaining the current 
mode; if necessary, callers to Current_Mode block until it has a value. 
This can be achieved by the environment task executing the 
initialization code for the package during elaboration, or by an 
initialization task in the package body.

> It would be if I was writing the Ada language. We're stuck with
> "Boolean". 

I'm glad you're not. "_Type" on the end of names is just 5 wasted 
characters. File_Type is about the only poorly named predefined type in 
the language. But let's not get into that discussion again. I've worked 
on systems that used the _Type convention, and it's workable.

> That is not just true of variables; add 1 undocumented
> function/procedure/package/task to the system, and you have a problem.

Yes, but not generally an increase in coupling and decrease in cohesion.

> Hmm. I guess I don't know what you mean by this. Above, you suggested
> replacing Distribute mode by a getter/setter, where the setter
> enforced the design rules. I assumed you meant that getter/setter
> design was better than the global variable it replaces. Now you are
> saying something else, but I don't know what.

I trust I've clarified this.

> Yes. And "the logic" can be as small as a 10 line function, or as
> large as a 90k multi-cpu program; each has need of some state that is
> visible to the entire subsystem.

They need to be able to access the value, but not to modify it. Global 
variables may be modified from anywhere.

> How did you set the variable in unit tests?

By faking the message.

> That I have not seen. Well, I guess I have to count Microsoft software
> in that; some people seem happy with it.

The customers of the SW designed around large numbers of undocumented 
global variables seemed satisfied with it. They weren't looking at or 
modifying the SW. In each case there were 1 or 2 people who had the 
whole system in their heads; that's the reason they were able to modify 
it. I guess I have a smaller head than they. And if those people ceased 
to be available, there would be big trouble.

> now you have :).

I still don't agree.

> "large numbers" and "undocumented" are the key here, and as I pointed
> out above, that description applies to other aspects of the software
> as well; large numbers of small functions, or large numbers of
> threads, are just as bad (possibly worse) as large numbers of global
> variables.

I'd be perfectly happy with an Ada-like language that didn't allow 
variables in package specs.

For the Mine Detector game, I have 2 protected Booleans in the spec of 
the package that models the mine field. (They're protected because the 
original design had a task so that user input could be obtained while 
the model of the mine field did its thing.) That's not a terrible 
design, but with the changes needed to use GtkAda (which involved 
getting rid of the task), in retrospect it would be better to store the 
values in the user-interface package, which determines their values, and 
have the mine-field package ask the user-interface package for them.

As you're probably aware, rules with "always" in them always have 
exceptions (including this rule). I have a rule that says always avoid 
global variables. I'll accept a small number of well documented global 
variables sometimes if the alternative is worse.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57