the 2 problems that globals introduce are
1. namespace collisions
2. point of origin problem
where a namespace collision is the inconsistent use of a global
variable within an application
eg.
// one point in the application
$GLOBALS['curUser'] = array('username' => 'bob', 'userId' => 5);
// another point in the application
$GLOBALS['curUser'] = new stdClass();
$GLOBALS['curUser']->username = 'bob';
$GLOBALS['curUser']->userId = 5;
and what im calling the 'point of origin' problem, is the ambiguity
introduced by global variables. when reading through the code of an
application and you encounter the use of a global variable, where was
that variable set? if not in the same file, then youll have to start
looking. you may not even be able to determine where the value is
getting set by looking through the code, that is, you might have to analyze
the runtime behavior of the application. and with the $GLOBALS array, this
can be cumbersome because there is no way (that i know of) to add implicit
logging to setting of values within.
now, whether you or your team or business or w/e will have to deal with
these
problems depends on what sort of conventions, if any, are used to work with
globals (or whether theyre used at all ;)).
to make them work in a team environment you should have some external
documentation
that establishes clear usage guidelines and outlines the purpose (or
declares 'namespaces')
within the $GLOBALS array. so you might say "$GLOBALS['user'] is designated
to contain
user data, which will be a record from the users table in our database". it
will be an array.
at that point if someone uses $GLOBALS['user'] for something else, or
changes its data type
or something, you can say, well youve violated our convention here so youll
have to clean that up.
there is the issue of working with code from other parties and this is where
things
can still get messy. say that you have your conventions and everything is
hunky-dory; then you
decide to use some third party code, and it uses one of your global
'namespaces'.
so for example you get some third party code and within it, for whatever
reason $GLOBALS['user']
(referenced earlier) is being read or set. well if you want to use that
code, youll have to refactor
either yours, or theirs.
object oriented development helps with some of these problems, but it is not
by itself a silver bullet.
for example with singleton
http://www.phppatterns.com/doku.php/design/singleton_pattern
problems 1, and 2 above are still relevant. php is introducing namespaces
soon enough, but prior
to those class name collisions are generally resolved in php by prefixing a
class name
eg.
class User {}
becomes
class MyBiz__User {}
problem 2 though is relevant depending on what the singleton is used for.
suppose it only contains
2 values, a reference to itself and one datum, which is set in the private
constructor (or another private
method invoked as part of the constructor). this is the most trivial case
and it is not really subject to
the problem. however, if a singleton were to have getter and setter methods
problem number 2 above
can occur. the good news here is that since singleton is a class you write,
adding logging is trivial
so you should be able to track down those spurious cases where a value is
set in one portion of the
application and read in another.
i happen to know that facebook uses globals, and i just thought i would
mention it as a 'successful'
yet perhaps 'code not so great' example of a large application using
globals.
if you are to use globals, then establish conventions.
the worst stuff i have ever seen is use of other superglobal arrays for the
same purpose as what the
$GLOBALS array is intended to be.
eg.
// one part of the application
// NOTE: this value did not orginate from the request
$_POST['someVal'] = 5;
// later in the application
$myVar = $_POST['someVal'];
that is just plain bad if you ask me (and they didnt even put the note!).
-nathan
