From: "Brian Smither" on 5 Oct 2010 15:47 I am running into a variable collision. The project I'm developing is NOT guaranteed to be operating on PHP5. Any solution I find should (hopefully) be able to run on PHP4 (yes, I know PHP4 is deprecated). I am building a bridge between two third-party applications. Both instantiate their respective database class assigning it to $db and I cannot change that. So, I am interested in solutions to this. I found a reference to a Packager class and will be looking at it shortly.
From: chris h on 5 Oct 2010 16:01 Just to clarify, both packages are instantiating and calling their respective database classes from the $db var, which is in the global scope. Is this correct? This is why I hate the global scope, I hate it, I hate it! On Tue, Oct 5, 2010 at 3:47 PM, Brian Smither <bhsmither(a)gmail.com> wrote: > I am running into a variable collision. The project I'm developing is NOT > guaranteed to be operating on PHP5. Any solution I find should (hopefully) > be able to run on PHP4 (yes, I know PHP4 is deprecated). > > I am building a bridge between two third-party applications. Both > instantiate their respective database class assigning it to $db and I cannot > change that. > > So, I am interested in solutions to this. > > I found a reference to a Packager class and will be looking at it shortly. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: "Brian Smither" on 5 Oct 2010 17:02 >Just to clarify, both packages are instantiating and calling their >respective classes from the $db var, which is in the global scope. >Is this correct? I would say yes to the way you are asking. Take the following two applications. The four respective statements are in each their respective script. Application A: <?php class foo {} $db = new foo(); $outA = barA(); function barA() { global $db; include("Application B"); } ?> Application B: <?php class bar {} $db = new bar(); $outB = barB(); function barB() { global $db; } ?> The bridge project is operating in A and include()'ing the script that is B (as I have not found an API for B). $db in B is colliding with $db in A.
From: chris h on 5 Oct 2010 17:18 Short of refactoring ApplicationB, can you set it up as a SOAP/REST service that AppA calls? On Tue, Oct 5, 2010 at 5:02 PM, Brian Smither <bhsmither(a)gmail.com> wrote: > > >Just to clarify, both packages are instantiating and calling their > >respective classes from the $db var, which is in the global scope. > >Is this correct? > > I would say yes to the way you are asking. Take the following two > applications. The four respective statements are in each their respective > script. > > Application A: > <?php > class foo {} > $db = new foo(); > $outA = barA(); > function barA() { global $db; include("Application B"); } > ?> > > Application B: > <?php > class bar {} > $db = new bar(); > $outB = barB(); > function barB() { global $db; } > ?> > > The bridge project is operating in A and include()'ing the script that is B > (as I have not found an API for B). $db in B is colliding with $db in A. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
From: David Harkness on 5 Oct 2010 17:45
If you have total control over application A which contains the bridge code, the easiest is to change it to use a different global variable, $dbA. This must not be doable or you wouldn't have asked. If you have control over the bridge code, and it alone calls A and B, then you could swap the $db variables between calls: $db = null; $dbA = null; $dbB = null; function copyPersons() { useA(); $persons = loadPersonsFromA(); useB(); savePersonsInB($persons); } function connect() { global $db, $dbA, $dbB; connectToA(); $dbA = $db; unset($db); connectToB(); $dbB = $db; unset($db); } function useA() { global $db, $dbA; $db = $dbA; } function useB() { global $db, $dbB; $db = $dbB; } This is the simplest implementation. You could get trickier by tracking which system is in use and only swapping them as-needed, writing a facade around the APIs to A and B. It's ugly, but it works. David |