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.

In a new post to his blog today Sebastian Bergmann looks at a way you can test your privates (no, not that) - private methods in your classes with PHPUnit. The key lies in the Reflection API.

One question I get over and over again when talking about Unit Testing is this: "How do I test the private attributes and methods of my objects?" [...] PHP 5.3.2 introduces the ReflectionMethod::setAccessible() method to allow the invocation of protected and private methods through the Reflection API.

This method lets you, at runtime, change the access level on the method away from private or protected and down to public so the contents can be executed normally. Though he warns one thing about doing it this way - just because you can, doesn't mean it's a good thing. You application is meant to be tested in a certain way and you should probably stick to that.

Lorna Mitchell has a last minute suggestion of something to add to your web service that can really help out when developers using the API need it - a heartbeat.

The heartbeat shouldn't require any particular parameters or any authentication, since formatting data and passing credentials can be a stumbling block for those integrating with a service for the first time or those debugging issues. The heartbeat method can return some known data, perhaps an "I'm here" message, and maybe some version information.

She points out Flickr's flickr.test.echo call that does nothing but return whatever was sent to it. This kind of method can be very useful for applications that might need constant contact with the API or, inversely, need to know when the API isn't there and switch to an offline mode. A consistent heartbeat makes it easy to check these sort of things and to be sure that you get consistent feedback from your requests.

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.

In this new tutorial from DevShed today they continue their series looking at making helper classes for your applications. This time they're focusing on using methods without needing to create an object first - static methods.

The methods of the class that I [just] mentioned were declared implicitly dynamic, even though it's perfectly possible to call them statically, and the PHP engine won't raise any errors about this process. However, it would be much better to declare these methods explicitly static, thus taking advantage of the functionality offered by the text helper class without having to spawn an instance of it.

They show how to define the methods with the "static" keyword so they can be called outside of the class' scope. Code for the helper class and the code to put it to use.

New on DevShed today is the latest article in their "magic functions" series. This time they focus on the "clone" method to create exact copies of current objects.

In this fifth part of a seven-part tutorial on magic functions, we'll briefly review the sleep and wakeup functions, and then tackle the clone function. [...] So, with that goal in mind, in this fifth part of the series I'm going to take a closer look at the "__clone()" method, which as its name suggests, is called behind the scenes when using the "clone" PHP keyword.

Their example code adds on to the previous examples using "__get" and "__set" and adds in a method to catch the cloning of an object. It only outputs a string ("Cloning user object") when its called, but it lets you get the idea.

Continuing on in his refactoring series (part 1 & part 2) Sameer has posted part three - a method of replacing temporary variables with calls to other methods.

Temporary variables are a integral part of any code. But a splattering of the same all over can make your code hard to understand or modify. Replace temp with query is a refactoring method where you replace temp variable expressions with methods. This method is often also required before you use the Extract Method refactoring.

In his example, he takes a variable inside a current method (base_price) and replaces it with a method call by the same name resulting in a more reusable format other methods can call rather than just computing the value themselves.

Paul Gregg has shared a method he's come up with to determine if a given IP is within a selected range.

Unfortunately although people usually understand that an IP address is simply an unsigned 32 bit integer, and is easily determined, usually with $_SERVER['REMOTE_ADDR'], where the real challenge is - is in specifying the range within which they wish to check that IP address. IP ranges are usually specified in three common ways (in increasing complexity): wildcard, start-end range, classless inter-domain routing.

He looks at each method and includes descriptions and code examples as well as a link to the source code and a live demo of it in action.

Packt Publishing has posted a new article from Jani Hartikainen about the "magic methods" that PHP comes with - methods, properties and constants really.

Magic methods, which are class methods with specific names, are used to perform various specialized tasks. They are grouped into two: overloading methods and non-overloading methods. [...] Magic functions, which are similar to magic methods, but are just plain functions outside any class. [...] Magic constants, which are similar to constants in notation, but act more like "dynamic" constants. We'll also look at some practical examples of using some of these, and lastly we'll check out what new features PHP 5.3 is going to add.

He looks at the various functions/methods and constants (like __clone, __toString), some of the overloading methods like __call, and magic constants like __FILE__ and __CLASS__. He wraps it up by briefly discussing what PHP 5.3 adds in - a few new magic methods and constants (but no functions).

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.