the Rise of “Access Specifiers†(or, the Scoping Complexityof OOP)
In programing, a variable has a scope — meaning where the variable
can be seen. Normally, there are two basic models: dynamically scoped
and lexically scoped. Dynamic scoping is basically a time based system,
while lexical scoping is text based (like “what you see is what you
getâ€). For example, consider the following code:
subroutine f() {return y}
{y=3; print f()}
In dynamic scoping, the printed result is 3, because during evaluation
of the block all values of y is set to 3. In lexical scoping, “yâ€
is printed because any y in the block is set to 3 before f is called.
With regards to language implementation, Dynamic Scoping is the
no-brainer of the two, and is the model used in earlier languages. Most
of the time, lexical scoping is more natural and desired.
Scoping is also applicable to subroutines. That is to say, where
subroutines can be seen. A subroutine's scope is usually at the level
of source file (or a concept of a module/package/library), because
subroutines are often used in the top level of a source file, as
opposed to inside a code block like variables.
In general, the complexity of scoping is really just how deeply nested
a name appears. For example see in the following code:
name1; // top level names. Usually subroutines, or global
variables.
{
name2 // second level names. Usually variables inside subroutines.
{
name3 // deeper level names. Less often used in structured
programing.
}
}
If a programing language uses only one single file of commands in
sequence as in the early languages such as BASIC, there would be no
scoping concept. The whole program is of one single scope.
OOP has created a immense scoping complexity because its mode of
computing is calling nested subroutines (methods) inside subroutines
(classes). We detail some aspects in the following.
In OOP, variables inside subroutines (class variables) can also be
accessed thru a reference the subroutine is assigned to (that is, a
object). In OOP parlance: a variable in a class has a scope, while the
same variable when the class is instantiated (a objet) is a different
scoping issue. In other words, OOP created a new entity “variable
thru reference†that comes with its own scoping issue. For example:
class a_surface() {
coordinates={...}; // a variable
}
class main() {
mySurface = new a_surface();
mySurface.coordinates = {...}; // the same variable
}
In the above code, the variable “coordinates†appears in two
places. Once as defined inside a_surface, and once as a instantiated
version of a_surface, that is, a object. The variable as thru the
object reference apparently has a entirely different scoping issue than
the same variable inside the subroutine (class) definition. The
question for OOP language designers is: what should the scope be for
variables referred thru objects? Within the class the object is
created? within the class the variable is defined? globally? (and what
about inherited classes? (we will cover OOP inheritance later))
As we've seen, methods are just inner-subroutines, and creating objects
to call methods is OOP's paradigm. In this way, names at the
second-level programing structure often associate with variables (and
inner-subroutines), is now brought to the forefront. This is to say,
the scoping of subroutines are raised to a level of complexity as the
scoping of variables. (they are now both in the 2nd level of names (or
deeper).)
All in all, the scoping complexities of OOP as applied to different OOP
entities (classes, class variables, class's methods, object variables
and methods) is manifested as access specifiers in Java. In Java,
access specifiers are keywords “privateâ€, “protectedâ€,
“publicâ€, used to declare the scope of a entity. Together with a
default scope of no-declaration, they create 4 types of scope, and have
entirely different effects when used upon a variable, a method, a
constructor, and a class.
See this tutorial of Java's access specifiers for detail:
http://xahlee.org/java-a-day/access_specifiers.html
-----
to be continued tomorrow.
This is part of an installment of the article
“What are OOP's Jargons and Complexitiesâ€
by Xah Lee, 20050128. The full text is at
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.
The article is published in the following newsgroups:
comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns
Xah
(e-mail address removed)
∑
http://xahlee.org/