|The Working Programmer's Guide To Variables - Scope, Lifetime And More|
|Written by Mike James|
|Thursday, 22 August 2019|
Page 4 of 4
The final twist to the story is visibility.
Suppose a variable is in scope but you then declare another variable of the same name in an inner block. Presumably you would like to work with the newly declared variable and not the one defined in the outer block.
The outer block's version of the variable is said to be in scope but inaccessible or not visible and the new definition replaces it.
You can invent additional rules to make variables that are in scope but redefined visible. For example, you could insist that every block was named and then you could refer to a variable as blockname.variablename. If you leave off the blockname then it defaults to the current block.
If this sounds familiar then I am not surprised because it is exactly the mechanism that object oriented languages used for making clear which object method is to be used in an object hierarchy.
However, this said, many language designers have decided that such a name collision is not a good idea and will flag any attempt to declare a variable within an inner block that is already in scope as an error. For example, in C# the following is an error:
Python does things the other way round to most languages and you have to declare a variable to be global otherwise it is assumed to be local.
Existence is an aspect of variables that most programmers rarely consider because it is an obvious consequence of the type of language that they most use.
For example, in Fortran and Basic variables are usually static, in block structured languages such as Java, C and C# they are usually dynamic or automatic as the term "dynamic" is used for so many things.
In languages such as Fortran and Basic static variables are the norm.
In block structured languages automatic variables are the norm.
Static variables can be used to store state information such as the number of times a function has been called. As a static variable retains its value between calls you can simply add one each time the function is called. Automatic variables make it impossible to set up a use counter in this way because they are destroyed when the function terminates. In this case you have no choice but to use a global variable or at least one that lives long enough to retain the count.
Automatic variables minimise storage requirements by assuming that if a procedure isn't running then its local variables cannot be in use by any other procedure.
Of course in a block structured language automatic variables exist when the block they are declared in is executing and they are destroyed when the block is completed.
This existence rule is just an extension of the nested scope rule - if a variable is in scope then it exists if it isn't then it doesn't.
Even block structured languages normally allow the programmer to create static variables on demand. Usually by declaring them using a a STATIC modifier. Languages that don't have a STATIC modifier and so don't appear to recognise the existence of static variables allow you to create static variables as global variables. A variable that has global scope will exist for the whole program and so can be described as a global static variable.
You might be wondering what the advantage of static variables is that many early languages adopted them as the only type they provided?
Well the answer is that a static variable can be assigned to an area of storage by the compiler at compile time and it stays there at the same location throughout the run of the program. This makes static variables simpler and faster than automatic variables.
Automatic variables on the other hand cannot be allocated at compile time they have to allocated to storage at run time. Fortunately this isn't as difficult as it sounds because most block structured languages use some sort of execution stack.
When a new procedure is started the old variables are pushed on the stack and the new procedures are allocated. When the procedure is finished the original procedure's variables are pulled off the stack. Using the stack makes automatic variables very easy to implement.
Variables as Names
It is generally assumed that variables form some sort of immutable name system. If you have a variable called Total then it stores a quantity that you can forever think of as "the total". It is natural to think that variable names, name things. Unfortunately this starts to break down when the language becomes more advanced. A variable can be a mutable reference to an object and this means that the object isn't necessarily uniquely associated with the variable and its name.
var myPoint=new Point(x,y);
where Point is a constructor for a Point object. It is tempting to think that the new object is called myPoint but this isn't the case. The object is annoymous and myPoint is a variable that just happens to reference it. Consider:
now both myOtherPoint and myPoint reference the same object - so what is its "name"? Clearly it doesn't have a fixed name.
In both cases the "name" of the function is myFunc and many programmers regard this as fixed in some way. It isn't. For example:
Now you can call the function using myFunc or myOtherFunc and again what is the name of the function?
In languages that use variables to reference object the objects are annoymous and do not have fixed names - unless of course the language introduces a rule to make them fixed.
In many languages it is better to always think of a variable as a muatable named reference to an object and not the immutable name of an entity.
At this point you can now see that variables can be classified in two ways Scope - local, nested, global; and Existence - static and automatic.
No doubt there are other subtle ways of managing variables their scope, visibility, lifetime and so on - but this more or less corresponds to what most programmers have to deal with today.
in general when learning a new language you have to ask what the rules are for the binding of a name to an entity i.e. its scope and you have to ask about the question of the lifetime of that binding. There are many variations of possible answers.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
What Programmers Know
* Recently revised
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 22 August 2019 )|