[Pmwiki-users] Dev Q3: Avoiding Problems With Variable Scope in Add-On Scripts

[Steven Leite]

> You could always decrease the chances of a collision by prefixing your
> globally scoped variables with the name of the file in which they
> appear or something.  (In fact, I've occasionally thought that PmWiki
> should do something like this just to "claim ownership" of certain
> variables and clearly define a "public interface".)

Yeah, I thought of that, but some of my variable names are long, and it was
getting very annoying having to prefix every variable in the script with the
script name.  But that is one option I guess.

> Is there a particular reason these variables aren't in a function?

Well, many of the variables are user-definable .. meaning, the user
shouldn't have to scroll down through the program checking all the various
function to see what variables they might want to change.

Example:  In X-Chat .. $NickName, $ServerName, $CodeBase, $Height, $Width,
etc .. these are all at
the top of the script.  Maybe what I'll do is move the variables out of
x-chat.php, and into x-chat-config.php .. then from one of the main
functions within x-chat.php, I'll include_once('x-chat-config.php') .. that
way the variables will be local to the function, correct?

Only downside is now we have two files to deal with instead of one.  I like
things all nice and need in one little package, but I guess it will avoid
potential collisions.

$Height, $Width for example are used in another script X-Include which
creates an IFRAME of an external web-page.

> AFAIK you're correct. PHP doesn't have the concept of anonymous
> scopes (i.e., bare blocks) so to get a new scope you need to declare
> a function.

What does AFAIK mean?   :-I

Thanks for your comments!

-S

>
> Alternatively, you can use the object oriented features of PHP
> to limit the scope of a variable to your object.  But then you need an
> object where an object mayn't fit.
>
> -Scott
> -- 
> Jonathan Scott Duff
> duff at pobox.com
>
>
>