The term "static variable" is a computer programming term that does not exist in the 4D lexicon. Static variables are local in scope to their module, or function, in which they are defined, but their life is throughout the program. A static variable inside a function cannot be called from outside the function (because it's not in scope) but is alive and exists in memory. The next time this function is entered (within the same program) the same chunk of memory would be accessed now retaining the variables old value and no new memory is allocated this time for this variable like other variables in the function (automatic variables). So basically the variable persists throughout the program. This is in contrast to local variables, whose storage is allocated and deallocated on the call stack.
Though the traditional concept of a "static variable" does not exist in 4D, static variables can be closely emulated in 4D. It can be emulated using Process variables in a process that exists until the application quits. 4D automatically provides such a process; the Application process.
Two of the known behaviors of the 4D Application process are:
- it cannot be aborted
- its process number is always one
Knowing these facts allows for some very efficient programming practices, the same advatages static variables provide to other higher level languages.
For example, take the practice of maintaining values that are not considered constants, but rather static, being maintained in process variables. Instead of establishing and populating these process variables in each new process consider using the Application process and the Process Communications commands:
The properties of the Application process teamed with the Process Communications commands facilitates a technique of populating all these needed static process variables in the Application process and then retrieving the stored values with the knowledge that they are always present in process number one.
So to store a fairly static value of a sales tax rate in an Application process variable, during the execution of the On Startup method, declare a variable with:
| C_REAL(SalesTaxRate_R) |
And assign it a value with:
| SalesTaxRate_R:=0.055 |
In any process that value can easily and efficiently be transferred to a Local variable:
| GET PROCESS VARIABLE(1;SalesTaxRate_R;$SalesTaxRate_R) |
For easy update, use a method that reads an easily updated text file and updates the sales tax so that no code change is necessary. The method would read the updated value from a file and then with the code below the value of SalesTaxRate_R is updated for all future use:
| SET PROCESS VARIABLE(1;SalesTaxRate_R;$SalesTaxRate_R) |
The benefits and advantages of this technique are:
- The first parameter "Destination process number" is always "1", the number for the Application process.
- The Application process, and its process variables, is going to live for the life of the applicaton.
- The containing method can be self-documenting and keeps the variable from being directly touched and manipulated by other methods.
- Without knowing the name or purpose of the variable it's value can be set.
- Any business rules regarding the variable, such as how many decimal places, or dates range, or string length can be enforced in one place.
- Dedicated Project methods used to set and retrieve values from Application Process variables vs. using Interprocess variables:
- Interprocess variable can be accessed and changed by any user.
- Project methods can be restricted to specific user groups in the method properties.