From: "Brian Smither" on
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
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

>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
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
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