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