On 1/13/08, Nathan Nobbe <quickshiftin@xxxxxxxxx> wrote:
>
> 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
>
A very cogent and detailed assessment of the issues, Nathan, and I
appreciate the time and thoughtfulness involved in writing your response.
My stance concerning globals is that, on PHP projects anyway, I work alone,
use longish and very descriptive variable names, and most always only use
globals for static data needed for calculations of some kind. But I
certainly appreciate that in a team environment and when working on very
large projects, the odds of globals usage, especially without documentation
and adherence to a standard, can lead to the problems described above.
In general, I agree with Stut's response delineated earlier in this thread,
that a careful and circumscribed use of globals has a place in PHP
programming.
David
