Re: [Php-java-bridge-users] PLEASE name globally visible variablesvery unique!

[<php...@li...>]

Hi Jost,=20

> -----Original Message-----
> From: php...@li...=20
> [mailto:php...@li...]=20
> On Behalf Of php...@li...
> Sent: Montag, 10. September 2007 11:32
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] PLEASE name globally=20
> visible variablesvery unique!
>=20
> ...
> how can a temporary variable, which is used only within the=20
> Java.inc block, break your application?

OK - maybe "global" was the wrong term here. It's not really "global"
in the PHP sense. Apologies!
But it is "global" in the sense, that obviously the code, that I am
using (a widget library for which I was creating additional widgets
that then get dynamically loaded) creates an environment into which
that widget code gets dynamically loaded and embedded and in that
environment there obviously already exists a variable "$version".

> ...
> $version is a variable which is used only in the if() block.=20
> Since php currently doesn't support name spaces, it is=20
> created in the global environment instead. Whether or not an=20
> included library uses temporary bindings in the global=20
> environment should not affect a well-written application.

If there already exists a variable "$version" OUTSIDE (i.e. before)
the if-block, then obviously it takes that variable (and does not
create and use a new local var) and so overwrites its value, i.e. that
statement has an outside noticable effect.

> This means that we have to prefix all *temporary* variables=20
> with java_. I don't think this is a good idea.=20

Well - if you want to similar effect in other environments, then I
guess this would be needed. However, I just checked again, it seems
that $version was actually the only var that is used in that way.
Everything else seems to be used inside functions or classes and
should thus not harm. And all others var and constants that I found
during my quick glance ($JAVA_BASE, JAVA_HOST, JAVA_SERVLET,
JAVA_LOG_LEVEL, etc.) are already named such, that they are rather
unlikely to clash (and if they do, the names already suggests where to
look...). I hope I didn't miss any, though.
=20
> > I even suggest to NOT use any variable here, but to write=20
> this snippet=20
> > as
> > follows:
> >       ...
> >   if ((version_compare("5.1.2", phpversion(), ">"))) {
> >       $msg =3D '<br><strong>PHP '.phpversion().' too=20
> old.</strong><br>\nFor
>=20
> How does this help? The temp var $msg is also created in the=20
> global environment.

Agreed - one could even compose the msg directly in the method call
thus avoiding the declarartion and use of $msg, but since that
variable is only used in the subsequent die(...) anyway, I did not
consider that an issue, while the use (and possible modification) of
"$version" obviously IS an issue and should be avoided.

Look, I didn't mean to cause a major headache here. I only reported a
problem that I banged into using the PHP/JavaBridge in my environment
and a IMHO really minor change, that allows to fix this and avoid
similar griefs for others in the future.=20

Michael