Wiki Home

Variable Scoping


Namespace: SQL
First let's separate the Visual FoxPro variable declarations from the general concepts of variable scoping. In the general concepts of variable scoping we can organize variables into some very distinct groups;
  1. Object properties - Object properties may be public, that is the object allows the property to be read and/or assigned values by other objects or code outside of the one that owns the property. Properties may be protected, that is they can not be read or assigned a value by anything but the object that owns the property.
  2. Local scoping - Local scoping of a variable means that the only procedure that can manipulate the variable is the procedure that creates it. NO other procedures can read or write to that variable.
  3. Static scoping - Same as local but in addition the variable retains its value after the procedure ends so that upon the next entry to that procedure the variable has the value it had at the last exit from the procedure. (VFP does not have this scoping available).
  4. Modular scoping - The variable is read and write for the procedure that creates and all other procedures called from that one, that is it is local to the module (group of procedures).
  5. Global scoping - The variable is read and write for the entire application.

Visual FoxPro has variable declaration commands that allow us to create variables of the various scoping levels (except for Static). VFP's declaration commands are not an exact parallel to the general scoping concepts. The declaration mechanisms in VFP are;
  1. Object Property - Object properties may be declared as Protected or Hidden to limit the ability of outside objects or code from manipulating them.
  2. PUBLIC - The PUBLIC Declaration creates the variable and assigns it a value of .F. The life time of a PUBLIC variable is from the time of its creation until you either quit VFP or you release the variable from memory using the RELEASE command.
  3. PRIVATE (default) - Simply assigning a value to a variable creates a private variable. The PRIVATE declaration does NOT create the variable, it hides any existing variables with the name being declared that may already exist in memory thereby protecting those variables from being effected by the use of the new PRIVATE variable. The lifetime of a private variable is from the time of its creation until the procedure it is created in ends or you release it from memory using the RELEASE command. Private variables are visible to the routine that created them and all other routines called from that one going down in the calling stack.
  4. LOCAL - The LOCAL declaration creates the variable and assigns it a value of .F. The lifetime of a LOCAL variable is the same as that of a PRIVATE variable although the visibility is limited to only the routine that declared the variable.

Using VFP's declaration commands you can create variables that meet the general scoping concepts, for example;
General Scope VFP Method of Scoping
Object Property
Define a class and add properties to it. The new properties can be made public, protected, or hidden as you wish.
Local Scoping
Declare the variable as LOCAL
Static Scoping
Not possible in VFP
Modular Scoping
Declare the variable as PRIVATE in the top level program of the module.
Global Scoping
Declare the variable as PRIVATE in the top level program of the application.

Notice that we can cover the Global scope without using a PUBLIC declaration. PUBLIC and global are not synonymous. In fact the only difference between a PRIVATE variable declared at the top most program of an application and a PUBLIC variable is that the PUBLIC variable will outlive the routine that creates it. The ONLY time you need to declare a variable PUBLIC is if you need for that variable to hang around and be available after the routine that creates it ends. If you need to create a variable that remains in memory after the routine that creates it ends that is a symptom of a serious application design problem.

There can be a very animated discussion as to whether global variables are a good thing or a bad thing with strong and valid arguments on each side of the issue, however I would propose that there is no equal discussion regarding PUBLIC variables. Since the only thing unique about a PUBLIC variable is that it outlives the routine that creates it there is no redeeming value to a PUBLIC variable, it is simply a bad design to use them at all except for a very few very specific situations most of which have to do with the development environment and the debugging process.
( Topic last updated: 2008.07.21 12:27:05 PM )