> ...
> Obviously, there is no perfect solution using Ada.  Perhaps we should consider
> static variables in the next version?  Although I am sure it was already
> discussed previously.  I just haven't heard the arguments and I'm not sure
> which way I would lean.  But I have never seen a serious need for a local
> static variable...

Having static local variables breaks a very nice feature of Ada that
variables are elaborated and initialized in a straightforward order,
and all variables in the same scope have the same lifetime.

By contrast, the rules for when local static variables are initialized
in C++, and when they get "destructed," are not pretty.

In general, an abstraction (e.g. a package) has "state".  If you bury that
state inside a single subprogram of the abstraction, finding the state and
understanding it is that much harder.  All of the subprograms of a
package work together to implement the abstraction, and hence it is
generally very appropriate that they all see the state, and can update
it as appropriate.

It is true that for some simple situations, only one subprogram
needs ever to see or update a particular piece of state.
But as the abstraction grows, it is almost always the case
that additional operations are added, and then the local static
variable ends up having to be moved outside its original "home"
anyway.

Better in my view is to think of the state of an abstraction
as a whole, organize it in a reasonable fashion with appropriate
comments, invariants, etc, and then verify that the various
subprograms of the abstraction preserve the desired invariants.

> Todd Coniam

-Tucker Taft  [log in to unmask]