In article <jqdfhl$rom$4@online.de>,
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
reply) wrote:

> In article <jqdf6c$do9$1@speranza.aioe.org>, dpb <none@non.net> writes:
>
> > > I agree, hence my proposal for one routine to "USE" what would otherwise
> > > be a local variable in another routine: only declared at one place, and
> > > within the units which use it.
> >
> > I think that is just evil, meself...if they are that restricted make
> > them arguments to the function or have a specfic module that
> > incorporates them if they are, indeed, to be global.
>
> Neither function calls the other directly. Yes, one can pass a variable
> through several levels of routines, but that is even worse in terms of
> readable code.

Then this makes your proposal even more odd. I thought that one
routine was supposed to declare the variables, and then other called
routines were supposed to access them (like a contained routine, but
compiled at the same level within the module) while the calling
routine was active.

If the two routines that share the data are called separately by the
other calling routines, then they should treat their shared data
symmetrically. The shared data should be declared somewhere else,
and the routines that share it should all access it in a more or
less equivalent/symmetrical way. That is exactly the way it would
work with module variables.

>
> > Don't screw up data-hiding and scope by somesuch illbred method of
> > "well, these two are needed but instead of making a proper interface
> > I'll just make them visible by this shortcut".
>
> Actually, I think this shortcut is clearer in this case, since only the
> routines involved have anything to do with the variables. Yes, one can
> put them in a separate module, but this is creating a high-level
> construct for a low-level problem.

This seems like a high-level construct for a high-level problem.
This is shared data by equivalent routines in the calling hierarchy.
Module variables are used in cases like this, where the routines are
at the same levels and they both operate on/with the shared
variables, and they are also used when a high-level routine sets
some information that is then later used by lower-level routines.
The logical high-level separation of data and code is what allows
this flexibility. Your approach associates the data with one of the
routines, and then acts like a low-level hack to make it accessible
to the other routines.

It seems to me like module variables are the exact fit to your
programming problem. They provide a clear, simple, and unambiguous
solution. Your proposed approach would be obscure, complicated, and
ambiguous; :-) it just does not seem like a good fit to your problem.

If you are worried that it will complicate your build process by
having to create a new file with that data module, then that is not
necessary. The module can be defined in the same file as the
subroutines. In fact, in this situation I think that would probably
be best. There is not a one-to-one mapping between files and
modules, a file can have several modules within it. I usually put
these small modules like this up at the top of the file, so the
compiler sees the definition before it sees the USE statements, but
I don't think most compilers care where they occur. That is the way
my example was structured in my earlier post, the data modules were
first and the subroutine modules were last.

$.02 -Ron Shepard