Re: [SPARK] Code safety and information hiding

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
.

Relevant Pages

  • Re: [SPARK] Code safety and information hiding
    ... around thousands of undocumented global variables. ... the documentation:). ... You want the code to enforce the design rules. ... During runs of many unit tests together, ...
    (comp.lang.ada)
  • Re: [SPARK] Code safety and information hiding
    ... I don't want to seem to give permission for modifiers of the system to create global variables that are more complex or have more restricted situations when they may be accessed. ... -- Returns True if the mode change is legal; ... If your SW determines a value in one place and stores it in another, that's an indication that you may need to rethink your design. ... I've worked on such systems where the determination of which is the active processor is made by another part of the system, so it is necessary to distribute that value to the processors. ...
    (comp.lang.ada)
  • Re: Design Notation VHDL or Verilog?
    ... fixed point arithmetic then the fixed point package will help your ... you can add in any pipelining needed. ... With the hardware block multipliers in many FPGAs, ... I use HDLs to design hardware and ...
    (comp.arch.fpga)
  • Re: Execute Package Task and setting its inner Package Global Vaiables
    ... Ok So you want to retrieve the values of child package Global Variables and use them in you Parent as well as setting child global ...
    (microsoft.public.sqlserver.dts)
  • Re: Global variables done right
    ... Lisp for the first time. ... deficiencies in the design of Common Lisp. ... three problems with CL's design when it comes to global variables: ... a conforming implementation of Common Lisp could expand DEFCONSTANT ...
    (comp.lang.lisp)