On the php|architect site there's a recent post that splits apart the singletons versus static methods debate that seems to com up every once and a while with a better suggestion - dependency injection.

Much more important than performance is the fact that both static methods and singletons suffer from major drawbacks. When it comes to deciding between the two, you might forgo the benchmark comparison and choose the third-party candidate: dependency injection.

He mentions the "dark side" of both static methods and singletons and how dependency injection can help rid your code of both. Instead of focusing just on the benchmark numbers, DI helps you keep your code more well-structured and "smarter" by scoping things to where they need to be and making them easier to test.

Doru Moisa has written up a new post with some benchmarks comparing static calls versus singleton calls for a few different situations.

n the past several months I've been working with a rather large application built with symfony. I noticed that symfony makes heavy use of the Singleton pattern (other frameworks, like Zend do that too); everywhere in the code [...] Notice the amount of code needed by the Singleton pattern. Except the [shown] method, all the code in the class makes sure you have only one instance at any time during the execution.

He shows how to replace the standard singleton logic with something more specific and decides to test the two methods, seeing which of them can handle the most requests per second. His sample code is included for both the scripts called and the test script run. In all instances, the static call won out over the singleton instance easily. Even when tested with the Facebook compiler, the results were still the same.

Sebastian Bergmann has two recent posts dealing with some of the more difficult topics in unit testing. One looks at sharing fixtures between tests and the other talks about stubbing and mocking static methods in your tests.

From the first of the two tutorials:

A good example of a fixture that makes sense to share across several tests is a database connection: you log into the database once and reuse the database connection instead of creating a new connection for each test. This makes your tests run faster.

This fixture sharing example uses the setUpBeforeClass and tearDownAfterClass methods to create and destroy the connection.

In the second article Sebastian shows how to mock up a sample static function and mock it with the "staticExpects" helper.

DevShed finishes off their series on data validation with this eighth part - a look at using static methods to create a simple validation helper class (a rework of earlier code).

The methods of the [previously created] helper were always called in the object scope, implying that there was a previous instantiation of the class. In this particular case, this process is completely unnecessary, aside from encouraging a bad programming habit. Therefore, in this last tutorial of the series I'm going to improve the source code of this validation helper class by declaring all of its implemented methods static.

In the code they redefine their methods (like validate_int and validate_alpha) to be static and directly callable without having to make an instance/object of the class.

New on DevShed there's the latest part of a series of tutorials they've written up (fifth of eight) about building automatic loading functionality into your applications. This time they change up their class to make the their loading function accessible outside of a class object.

To avoid an eventual (and unnecessary) instantiation of the loader class, it would be helpful to declare the mentioned "load()" method static. Thus, bearing in mind this important concept, in this fifth part of the series I'm going to enhance the signature of the "Loader" class created previously by turning its loading method into a static one.

They change the definition of the function to be "public static" making it callable both through the "self" keyword and outside the class with the "::" operator.

Continuing their look at static methods in PHP, DevShed has posted this new tutorial (the second in the series) focusing on using the methods to create a simple loader application.

As its name suggests, a file loading program (or a resource loading program, to express the concept more accurately), is simply a PHP module that takes care of including, usually via its set of "include()/require() native functions, files that are required by an application to make it work as expected. [...] It's worthwhile to mention, however, that it was necessary to create an instance of the aforementioned class to load a determined file. This is a process that can be completely avoided in terms of good coding habits. But how can this be achieved? Well, it's feasible to statically call the class's load()" method, preventing its unwanted instantiation.

The code examples of the simple loader class (a require_once wrapped in a try/catch) and a usage example.

Just for those PHP & Oracle users out there Chris Jones has posted a new entry to his Oracle blog detailing the different ways you can compile with oci8 support.

PHP OCI8 can be built using libraries from a full Oracle Database (or Database "Client") install, created from running the GUI installer. This is often referred to as an "ORACLE_HOME" install, since an environment variable of that name is set to the installed Oracle software directory. [...] Another dimension to the install is that PHP extensions can be statically compiled into the PHP executable(s), or built as shared binaries. If OCI8 is built as a shared library it is loaded into PHP as a result of setting the php.ini option "extension=oci8.so".

There's eight different methods he mentions including building it as a shared module, using the normal Oracle libraries to build and using the Instant Client libraries to run the build.

Stefan Koopmanschap has posted about static methods and comparing "static public" to "public static" (including a popularity graph).

Ever since starting with PHP 5 object oriented development, all documentation I read on the topic seemed to suggest that the only way to write the method keywords is "public static". I've been following along those lines, and for a while I really thought any other order would trigger errors. Only recently I found out the other way round is actually nicer.

In his opinion, the "static public" keyword combination (versus "public static") is "more beautiful" than its inverse counterpart. He even asked about it in a twitpoll and got these results - "public static" winning out as the popular choice. If you want to voice your opinion, you can still get in on the poll.

Adding on a bit more to a previous post of his look at test isolation (ex. global variables from one test do not effect any others') with an update he's made to the PHPUnit code concerning the isolation.

Since the previous posting, I have added a backup/restore mechanism for static attributes of classes to PHPUnit. This is yet another feature of PHPUnit that makes the testing of code that uses global state (which includes, but is not limited to, global and superglobal variables as well as static attributes of classes) easier.

Two graphs illustrate the difference - one showing a normal run and another with this new feature in use and showing off the performance increase it can give.

Padraic Brady has posted two more updates in his "Zend Framework Page Caching" series - an "A" and "B" for the third part looking at tagging the static files you've cached from the output of your pages.

Expiring multiple caches linked to a specific change is easy to accomplish using Tagging, where we tag caches with keywords and clean caches based on those keywords. Unfortunately, static files can't be tagged in the normal way since their filenames must be constant. [...] In a sense, we're creating a cache within a cache.

The first part of this look at static caching looks at how to integrate a caching component, one that supports tags, into a Zend Framework structure. In the second part he takes it one step further and makes some changes to refactor and clean up some of the Cleaner component's code.