Questions

• Is it desirable to remove all "normal" global variables?
• How should we consider autoglobals ($_SESSION, $_REQUEST, etc.) in relation to "normal" globals?
• How should we consider static variables within methods in relation to "normal" globals? (This has implications for the Singleton pattern.)

Note

I'm not advocating for a whole bunch of developers to attack the code and remove all globals (unless, of course, they feel like it). I'm advocating for adopting some small practices and habits which will have the eventual effect of removing all globals--or at least enough so that some day we get pissed off enough to finish the job in an evening. I liken this to Chuck's emphasis on the small practices of factory and singleton patterns, which produced a highly flexible framework uniformly supporting lots of network protocols and database backends as the emergent design. --Jason

Jason's Rationale

When I've contributed to projects with fewer global variables, I've noticed that the flexibility and maintainability of the code has been significantly greater, and I have more fun working with it. My theory: if there are no globals, we can predict that an object doesn't play with any toys that we haven't given it.

With globals, the protocol for usage of an object could be complicated and implicit. Given the class:

class Foo {
    function Foo($number) { ... }
    function doBar($number) { ... }
}

I might reasonably expect the protocol for using this object to be:

$foo = new Foo(12);
echo $foo->doBar(47);

when in fact, the protocol could be:

$GLOBALS['calculator_helper'] = new CalculatorHelper("pgsql://localhost/db_cache");
$_SESSION['state'] = 'initializing';
$foo = new Foo(12);
$_SESSION['state'] = 'calculating';
echo $foo->doBar(47);

If I were to remove global references, I'd rewrite the interface like this:

class Foo {
    /**
     * @param CalculatorHelper:: $helper
     */
    function Foo(&$helper, $number) { ... }
    function setState($name) { ... }
    function bar($number) { ... }
}

While not perfect, I'm comfortable that this better communicates the object's protocol.

So, a no-globals rule means:

1. I can reuse objects more confidently in different contexts, since I can trust that it needs only what it explicitly asks for by way of constructor and method call signatures.
2. I can very easily find out what the object depends on by looking at its usage.
3. I can more easily find method calls and constructions of a class, for adding parameters and refactoring and such.

How To Implement

• Encapsulate request in an object
• Instantiate master Horde object (e.g. $horde = new Horde($config);)
• InstantiateApplicationObjectRefactoring
• Page handling become method object (e.g. $page = new Turba_BrowsePage($app, $request); $page->execute();)

--Jason

• Instantiation of the Horde object doesn't make sense to me because it introduces another global object. And why is using a static Horde class bad?
• Usage of $_SESSION makes a lot of sense to me, because it is very clear that we are dealing with session state. Encapsulating this in a class or object obfuscates the code.

--Jan

Given my rationale,

• Like the ApplicationObject, I would want to fold globals into the global $horde by adding methods like getPrefs() and getBrowser(). Ideally (which is ideally enough that we may never actually get there) we would make eventually make the $horde unglobal, and construct a Horde object at the top of every page pointing to the config directory. We would easily end up killing more globals than the one we introduce.
• A static Horde class isn't "bad" per se (that's relative), but see above--I think we have something to gain. I think global variables like to hide in them because they are static and have no instance data, and so calls to methods on static classes become implicit dependencies.
• The $_SESSION issue (and I'll admit that $_SESSION is the autoglobal I'm the least concerned about) is about making protocol explicit--it's also the easiest to solve. In my Ingo test I just used $ingo = &new Ingo($_SESSION); (passed by reference).

I normally try not to spam people with a lot of words, but have failed miserably this time ;-) Let me know what you think (or anyone else, for that matter).

--Jason