[cvs] [Wiki] changed: RemoveGlobals

[Jason Felice]

eraserhd  Wed, 16 Aug 2006 10:18:13 -0700

Modified page: http://wiki.horde.org/RemoveGlobals
New Revision:  1.4
Change log:  pedantic style edits

@@ -9,19 +9,19 @@
  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 therefore it is more enjoyable to work with the code.  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.  This has a number of effects:
+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 following class:
+With globals, the protocol for usage of an object could be complicated and implicit.  Given the class:
  
  <code>class Foo {
      function Foo($number) { ... }
      function doBar($number) { ... }
  }
  </code>
  
-We might reasonably expect the protocol for using this object to be:
+I might reasonably expect the protocol for using this object to be:
  
  <code>$foo = new Foo(12);
  echo $foo->doBar(47);
  </code>
@@ -34,9 +34,9 @@
  $_SESSION['state'] = 'calculating';
  echo $foo->doBar(47);
  </code>
  
-If we were to remove globals, we would have to rewrite the interface for Foo:
+If I were to remove global references, I'd rewrite the interface like this:
  
  <code>class Foo {
      /**
       * @param CalculatorHelper:: $helper
@@ -48,15 +48,15 @@
  </code>
  
  While not perfect, I'm comfortable that this better communicates the object's protocol.
  
-So, a no-globals rule means to me:
+So, a no-globals rule means:
  
  # 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.
  # I can very easily find out what the object depends on by looking at its usage.
  # I can more easily find method calls and constructions of a class, for adding parameters and refactoring and such.
  
-++ How To
+++ How To Implement
  
  * Encapsulate request in an object
  * //Instantiate// master Horde object (e.g. {{$horde = new Horde($config);}})
  * InstantiateApplicationObjectRefactoring