Variable (Class instantiation) collision

Variable (Class instantiation) collision

am 05.10.2010 21:47:52 von Brian Smither

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

Re: Variable (Class instantiation) collision

am 05.10.2010 22:01:31 von Chris H

--0022152d61099542650491e4201c
Content-Type: text/plain; charset=ISO-8859-1

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

--0022152d61099542650491e4201c--

Re: Variable (Class instantiation) collision

am 05.10.2010 23:02:55 von Brian Smither

>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:
class foo {}
$db =3D new foo();
$outA =3D barA();
function barA() { global $db; include("Application B"); }
?>

Application B:
class bar {}
$db =3D new bar();
$outB =3D 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

Re: Variable (Class instantiation) collision

am 05.10.2010 23:18:25 von Chris H

--0003255747468c9b790491e53301
Content-Type: text/plain; charset=ISO-8859-1

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 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:
> > class foo {}
> $db = new foo();
> $outA = barA();
> function barA() { global $db; include("Application B"); }
> ?>
>
> Application B:
> > 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
>
>

--0003255747468c9b790491e53301--

Re: Variable (Class instantiation) collision

am 05.10.2010 23:45:33 von David Harkness

--001636832ef49b826b0491e59465
Content-Type: text/plain; charset=ISO-8859-1

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

--001636832ef49b826b0491e59465--

Re: Variable (Class instantiation) collision

am 06.10.2010 23:51:02 von Brian Smither

Gentlemen,

Thank you. The "Thing1 Thing2" approach worked.

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




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php