title: Loading multiple versions of the same class
body: <p>Let's say I release a code library as a standalone PHP class.  Someone then uses version 1.0 of that library in their application.  Later, I release version 2.0 of the library and that same someone, for any reason, needs to use both 1.0 and 2.0 side-by-side in their application because either he or I broke backwards compatibility with the new release.</p>
  
  <p>If the class names are different, it's easy enough to include and instantiate both because there's no naming conflict.  But if the class names are kept the same, we run into problems:</p>
  
  <pre><code>include /lib/api-1.0/library.php;
  $oldlibary = new Library();
  
  include /lib/api-2.0/library.php;
  $newlibrary = new Library();
  </code></pre>
  
  <p>This just won't work because we can't load two classes both with the name <code>Library</code>.  One alternative another developer suggested was to use namespaces.  The following <em>should</em> work:</p>
  
  <pre><code>namespace old {
      include /lib/api-1.0/library.php;
  }
  namespace new {
      include /lib/api-2.0/library.php;
  }
  
  $oldlibary = new old\Library();
  $newlibrary = new new\Library();
  </code></pre>
  
  <p>Unfortunately, this isn't very scalable.  It would work with a 2-instance situation (which, hopefully, I wouldn't have to use in the first place), but to scale it to 3, 4, 5, or more instances you'd need to have additional namespaces defined and set up,  If you're not using those namespaces in the first place, that's a bunch of unnecessary code.</p>
  
  <p>So is there a way to dynamically create a namespace, include a file, and instantiate the class contained within that file in a uniquely-named variable?</p>
  
  <hr>
  
  <p>Let me add some more clarification ...</p>
  
  <p>I'm building a set of libraries to be used by other developers who build plugins/modules for a couple of CMS platforms.  Ideally, everyone would always use the latest version of my library, but I can't guarantee that and I can't guarantee the end user will always upgrade their modules when new versions become available.</p>
  
  <p>The use case I'm trying to work with is one where the end user installs two different modules by two different developers: call them <strong>Apple</strong> and <strong>Orange</strong>.  Both modules are using version 1.0 of my library, which is great.  We can instantiate it <em>once</em> and both sets of code can benefit from the functionality.</p>
  
  <p>Later, I release a minor patch to this library.  It's versioned 1.1 because it doesn't break backwards compatibility with the 1.x branch.  The developer of <strong>Apple</strong> immediately updates his local version and pushes a new edition of his system.  The developer of <strong>Orange</strong> is on vacation and doesn't bother.</p>
  
  <p>When the end user updates <strong>Apple</strong> she gets the latest maintenance release of my library.  Because it's a maintenance release, it's assumed to be safe to completely replace version 1.0.  So the code only instantiates 1.1 and <strong>Orange</strong> benefits from a maintenance patch even though the developer never bothered to update their release.</p>
  
  <p>Even later, I decide to update my API to add some hooks to Facebook for some reason.  The new features and API extensions change a lot about the library, so I up the version to 2.0 to flag it as potentially not backwards-compatible in all situations.  Once again, <strong>Apple</strong> goes in and updates his code.  Nothing broke, he just replaced my library in his <code>/lib</code> folder with the latest version.  <strong>Orange</strong> decided to go back to school to become a clown and has stopped maintaining his module, though, so it doesn't get any updates.</p>
  
  <p>When the end user updates <strong>Apple</strong> with the new release, she automatically gets version 2.0 of my library.  But <strong>Orange</strong> had code in his system that added Facebook hooks already, so there would be a conflict if 2.0 was rolled in to his library by default.  So instead of replacing it entirely, I instantiate 2.0 once for <strong>Apple</strong> and, side-by-side, instantiate the 1.0 version that shipped with <strong>Orange</strong> so it can use the right code.</p>
  
  <p>The entire point of this project is to allow third party developers to build systems based on my code without depending on them to be reliable and update their code when they're supposed to.  Nothing should break for the end user, and updating my library when used inside someone else's system should be a simple file replacement, not going through and changing all of the class references.</p>