From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 25 Sep 92 16:30:12 GMT
From: sdd.hp.com!cs.utexas.edu!ut-emx!hasan@hplabs.hpl.hp.com  (David A. Hasan)
Subject: Re: Using Global Variables
Message-ID: <80453@ut-emx.uucp>
List-Id: <comp.lang.ada>

Comparing an "unencapsulated global" package:

>   package Contains_Global is
>      Global_Variable : Integer;
>   end Contains_Global;


to an "encapsulated global" package:

>   package Convert_Global is
>      procedure Put (Value : in     Integer);
>      procedure Get (Value :    out Integer);
>   end Convert_Global;
>
>   package body Convert_Global is
>      Is_This_A_Global_Variable : Integer; ----------- What do you say?
>
>      procedure Put (Value : in     Integer) is ...;
          [sets Is_This_A_Global_Variable]
>      procedure Get (Value :    out Integer) is ...;
          [returns Is_This_A_Global_Variable]
>   end Convert_Global;


Doug Smith mentions that


>In an attempt to limit the potential explosion of discussion about
>why one is better than the other--let's try to define the term `Global'
>first!  What is the Integer declared inside the package body?

The problem with the term "global" is that is just describes 
to topological- (visibility-) related aspects of the coupling.
However, in the sense of Constantine & Yourdon, there is much
more to coupling that just "who sees what"; the meaning of   
coupling includes "who knows what".

Applying this to the example above, even though the visibility
is essentially the same, the fact remains that
the latter ("encapsulated global") approach permits the
implementor to CHANGE the actual definition of the variable
WITHOUT affecting how clients read and write to it.  Thus
the nature of the client's knowledge about the "global"
is different, and therefore so is the coupling.

Although both approaches can usefully be called "global",
the former ("UNencapsulated global") approach introduces
MORE COUPLING between the package and its clients.  The
term "global" alonge does not distinguish between these.

PS. This is not necessarily a pedantic distinction.  If
    (at some later stage in the evolution of the package)
    the implementor decided that the value of the "global"
    quantity should be CALCULATED based on some other
    information, the latter ("encapsulated global")
    approach would allow the change to be made only in 
    the package of the body, requiring NO changes or
    recompilations of the client's code.  (E.g., polar
    or rectangular representation of complex numbers.)
-- 
 |   David A. Hasan
 |   hasan@emx.utexas.edu