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.n
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 v
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 t
>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 sc
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 v
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 respe
6 matches
Mail list logo
