Sebastian Bergmann has a new post today about a feature of the PHPUnit unit testing tool that has the possibility of breaking when objects are introduced - backing up the globals.

It is hard to test code that uses singletons. The same is true for code that uses global variables. Typically, the code you want to test is coupled strongly with a global variable and you cannot control its creation. An additional problem is the fact that one test's change to a global variable might break another test.

You can disable the backup option if you'd like by setting the $backupGlobals option in your test to false. This lets PHPUnit know that you want to leave the globals (and superglobals) alone during the run.

After hearing Stefan Priebsch's talk at this year's Dutch PHP Conference, something occurred to Derick Rethans - there was a small sort of issue with using namespaces and possible future PHP's own namespace.

One of the things that came up is the conflicts that can arise with internal classes. In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working

He offers a simple solution that can prevent this sort of conflict for the future - defining your "use" and then creating a new instance of the namespace into a variable instead of just an "as".

In a new post to his blog today, Stoyan Stefanov has a proposal to being something PHP users are very used to - superglobals - over to Javascript.

Javascript has implied globals. When you skip the var in var a = 1; and go a = 1;, then a becomes a global variable. Some consider this an error in the language. [...] In PHP on the other hand, variables are local. [...] So how about this: adopt the $GLOBALS convention in your JavaScripts?

His example proposes the creation of a GLOBALS object you can assign properties to that can be used anywhere. This helps to keep the variables you truely want to be global contained, though it doesn't do much except provide a convention.

On the SitePoint PHP Blog today Troels Knak-Nielsen asks th3e question "what's so bad about the singleton?" For all of its advantages, is there a darker side of the design pattern when it pertains to global variables.

As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I'll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.

He talks about what they are and how they're commonly used - sometimes with some unpleasant side effects because of their use of globals.

Arnold Daniels points out a quick method for creating what he calls "perl-like temporary variables" in the global scope of a script:

When writing code in the global scope, I often have a problem where I'm overwriting a variable. This happens even more often when I work on code of somebody else. Usually has the variable which does the overwriting is usually just a temporary variable.

His code is a simple few lines that shows how it could be used when trying to write information out to a file handle. Some of the comments on the post criticize his use of the global scope but Arnold comes back with his reasoning - mostly that there is already code in the global scope and that adding something else is only adding to it, not making things worse.

On the SitePoint PHP blog, there's a quick tutorial from Troels Knak-Nielsen about the creation and use of dynamic global functions in your PHP application:

Like many others, I prefer to use procedural PHP as a template language. While PHP's syntax makes it a practical choice for this, there is a problem with embedding dynamic content. [...] A single letter, regular function is undoubtedly the simplest way to extend PHP's syntax. Thinking about it, it's fairly obvious, but it just never occurred to me. [...] There is a problem though; Since this is such a good name for a function, chances are that someone else would use it for something different, or perhaps even for the same.

As a more viable solution, he recommends going dynamic and creating fumctions (via the call_user_func_* functions) and an addition to the $GLOBALS superglobal to make calling the custom function simpler.

As mentioned by Ed Finkler, there's a list of signs your PHP needs refactoring from Soledad Penades.

I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.

So here are the signs your PHP application needs a serious refactoring, right now

Included in the list are things like:

• Uses global variables
• Everything's an array
• The neverending switch
• Interface inconsistency

It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.

An official guide to choosing names for identifiers in userland has been added to the PHP manual on PHP.net. In his latest post, Lukas Smith talks about it:

So now we finally have some guidelines on how users should name their identifiers to be fairly future proof. This should hopefully help reduce the amount of pain people suffer when PHP adds new features like a class for Date or File handling. Although the two mentioned examples have settled on using DateTime and FileObject to get around the issue at least partially.

The guide itself is unfortunately spread over 3 pages, which does not seem to make sense since there is really not that much content there yet. Then again the guide may get expanded in the future. Anyways I recommend that every serious PHP programmer have a look at the guide. If there are any issues please let me (or the PHPDoc team) know. Otherwise make sure you adapt your internal CS to match this guide.

The guide talks about the naming of items in the global namespace (functions, classes, interfaces, etC), some rules to follow for internal identifiers, and some quick tips on naming to create pseudo-namespaces.

In his latest post, Jacob Santos talks about global functions and some of the dangers behind using them in your code (as per his own experience debugging with them in place).

When I develop in PHP and code functions, I always either place them in a file or place them at the top of the script. Well, this is more about C++ and how I totally freaked out my teacher, by breaking his paradigm of thought. You see, you can have a definition of a function at the top of the page and then code the body of the function later.

He soon discovered his problem in debugging the script - he was too used to having the global functions at the top (as in C++) and not mixed in with the code - or at the bottom of the script.

If there is something at least somewhat common about popular scripts that people use and extend, is that the functions are placed in organized manner. Reforming otherwise is a bitch and I remember rewriting the entire script anyway. You can't reform when you can't reuse anything.

From Vidyut Luther today, there's this new post that asks the question "Where do you 'define' your environment/global settings?"

I was wondering how people handled this situation themselves. I'm personally trying to decide whether my constants be in the class files, or a global configuration file. Right now I have a global.conf.php which contains things like (MySQL login info, include paths, table names).

So, my question is: Is it better to have one big configuration file, or should some things be defined on top of the individual classes ? (CONTACTS_TABLE.. is a clear example). I see pros and cons for both approaches.

He lists out pros and cons for the "one file approach" versus the "multiple specific definitions" method, for example:

• simple editing vs. easier to manage
• a single large file vs. multiple small files
• high memory usage on every page vs. lower memory consumption from loading only what's needed