DevShed has a new tutorial posted today looking to help you counteract the bad practice of wrapping procedural code in "class" constructs and provide some useful suggestions of how to avoid it.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

In a new post to his blog Sebastian Bergmann takes a quick look at using a static analyzer, clang and scan-build, to analyze the PHP interpreter (specifically during the compile process).

I have been tinkering with CLANG's static analyzer lately. This post summarizes how I installed LLVM and CLANG and performed the analysis of a build of the PHP interpreter.

He includes all the commands (unix-based) to get the clang tools/libraries installed in the correct places as well as what to add to your $PATH to get the "scan-build" command to work with the make and make install parts of the PHP compile process.

In an informal poll Lorna Mitchell recently asked fellow developers to weigh in on what static analysis tool they used on their code. She's posted the results to her blog today with one of the tools being a clear winner.

My interest was mostly because I'm working on a book chapter which includes some static analysis content, and there are a couple of these tools that I include in my own builds, but I don't do much with the output of them. However I didn't want to drop anything from the chapter if it was actually a valuable tool and I was just missing the point - pretty much all the tools got a good number of votes though, so I'll be covering all of the [options].

According to her results, the most used tool by developers is the PHP_CodeSniffer with the PHP Mess Detector and PHP Copy & Paste Detector tied for second place.

Eric Hogue has a recent post to his blog looking at one of the more tricky aspects of the latest versions of PHP (the 5.3.x series) - late static binding. In a nutshell, late static binding (LSB) lets static classes and methods work more correctly than before. Eric gets into a bit more detail than that:

It came out almost 2 years ago, but it to me that many programmers around me have no idea about it. Myself, I have learned about it around 6 months ago. The PHP documentation defines late static binding as a way to "reference the called class in a context of static inheritance." This definition didn't really help me the first time I read it. Fortunately, there are more explanations in the documentation, and there are good examples. If you haven't, you should read it.

To clarify, he includes a code snippet showing the use of the "static" keyword to correctly reference a static method. He also includes in interesting bit about when's a good time to use it.

On his blog today Victor Farazdagi introduces a new tool he's developed to help make the creation of static sites even easier - Phrozn, a static site generator that takes content and wraps it in a site's template and structure and outputs it for easy integration.

Given the scale of how client-side technologies (such as JavaScript) evolved, most of dynamic functionality can be implemented using client-side scripts + remote web-services (e.g. Disqus for comments). More than often we a going down that road even on our completely dynamic sites - it makes things more simple.

He gives the example of being able to write the content in VIM and run a single application - Phrozn - and generate the new page to add to the site. He sees it as a good alternative to something like WordPress where most people only use 1% of the functionality it offers. You can find out more about the project by looking into its documentation or you can just dive into the code by grabbing it from github. As a side note, several other tools, like Jekyll are "blog aware" and can be used similarly.

In this new post to his blog Bence Eros shares some of the frustrations and issues he's had when dealing with static methods and properties in his applications and how, with a bit of re-engineering, you might be able to have "life without static".

The problem with static members in PHP is the poor initialisation capabilities. The initial value of a static property can only be a literal or a named constant. [...] The same problem exists for non-static properties too, but the constructor is a dedicated place to initialize non-static properties. But since we don't have Java-like static constructors in PHP there is no place to do static property initialization. In a lot of cases people do it by putting the assignment statements after the body of the class, but this method is very ugly.

An alternate method he suggests is using a singleton to initialize and grab the value of a class value. He gives some sample code to show how it might be done, but warns that it might not be the right way to do things. It has "significant disadvantages" that could cause trouble down the road (for one, singletons make it difficult to unit test).

On the Content with Style blog today they take a look at some buggy functionality with parent:: they've found in the latest version of PHP, 5.3.3.

So, this app I hadn't been looking at in a few months did not work at all. I traced the bug down to a method that itself called a parent method. The parent only contains __call and __callStatic methods, and for some reason __callStatic was called, although the class it was called from was an object instance.

After using some sample code from the PHP manual, they spotted how things truly worked - the call is always sent to __callStatic when called from the extending class but not when called directly. Apparently they aren't the only ones that noticed the bug but noted that it was removed in PHP 5.3.4 to fix the issue.

Lorna Mitchell has a new post to her blog today talking about static methods and how to use them correctly in your code (as discovered accidentally in her own code).

I was confused recently to realise that I had accidentally called a static method in PHP dynamically from another part of my code; I expected PHP to output warnings when this is done. On closer inspection I discovered that: static functions can be called dynamically and dynamic functions generate an E_STRICT error if called statically.

She illustrates with some sample code that, when run with E_ALL and E_STRICT throws a warning from the strict side about calling a non-static method statically. She also talks about why it throws this warning for the non-static call on a static method. She also explains why, when a static method is called dynamically, no warning is thrown.

On the Stubbles blog today there's a new post from Frank Kleine showing how you can use a new feature of PHP 5.3 to perform dependency injection on static method - calling static methods with dynamic class names.

Developers who are familiar with the topic of clean code know that static methods are a problem, especially if it comes to testability. Static makes the code global, and if there is some kind of state involved it is even more a problem because this is global state then - both a maintenance and testability nightmare. [...] How can we keep our code clean and testable, at best without having a strongly coupled dependency to the class hosting the static method? Enter dependency injection for static methods.

He gives an example of how to use this to create a simple class that can change the name of the object an inner static function call is made to.

In his most recent blog post Maarten Balliauw proposes an idea of something to be included into PHP that .NET developers are used to as commonplace in their language - extension methods.

For the PHP-related audience, this is probably something new. Let's start with the official definition for extension methods: Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type.

He gives a code example of the concept, showing how you could add this sort of functionality to a PHP class with the help of the __call magic method and some of the Reflection features. The real usefulness, he notes, would be if the idea made it into the core rather than having to do it with the hack he's shown.