What follows isn't so much a PHP trick as a fix for something that really should work, but doesn't. Although the manual implies that the behaviour described below is specific to Zend Engine 1, all my tests were performed against Zend Engine 2.2, PHP 5.2.5.

His example compares making a new stdClass both with and without a reference on the it and var_dumps out the result. The method with the reference fails silently, however and isn't able to correctly assign it to the global. He recommends a work-around though - setting it directly to the $GLOBALS superglobal.

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.

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".

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.

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.

__autoload() is a magic function introduced in PHP 5 that provides a mechanism for on-demand loading of classes. After its inclusion in PHP, many argued that using such a feature is too magical or not a good design practice. Putting the religious debates over the appropriateness of __autoload() aside, its implementation does have one significant drawback: it is a function declared in the global scope. Once a function is declared, it cannot be redeclared. This means __autoload() can't be used effectively in shared libraries, since any other code could have already declared it.

Similar lazy-load functionality can be achieved on the class level by using __get().

He gives a short code example where the __get() call mimics the functionality of __autoload(), but the resulting object created is public, not global...]]> Wed, 09 Jan 2008 06:47:54 -0600 http://www.phpdeveloper.org/news/8961 http://www.phpdeveloper.org/news/8961 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.

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.

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.

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.