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