A big topic in the world of PHP recently has been interoperability between libraries. With the release of PHP 5.3 and the introduction of namespaces some discussion of new standards around the use of namespaces to promote the interoperability of autoloader implementations has started.

The goal of this blog post is to reach out to the all the PHP open source projects and applications in hopes to get them to join our initiative and give a vote for approval. If we can get the entire community behind this initiative it will make it much easier to get acceptance by the PHP core team and get this standard advocated in the manual on php.net.

If your project is interested in joining the initiative please join the google group http://groups.google.com/group/php-standards and help us change PHP for the better!

On the ITnewb.com site today there's a new tutorial looking at the encryption of passwords in your PHP apps using the RSA PBKDF2 standard - a "Password-Based Key Derivation Function" that uses a pseudorandom function/input with a salt run multiple times to produce your derived key.

When creating password hashes for storage, many programmers will run a password through MD5 once and call it a day, rendering those hashes very susceptible to attack if they're discovered. In this article, you'll learn how to create stronger hashes with PHP by using the RSA PBKDF2 Standard.

They create a quick function that takes in a few different values - the password to encrypt, a salt value, how many iterations to run, how long you want the derived key to be and which hash to use (in this case sha256).

Brandon Savage has posted a few suggestions about dealing with coding standards and how they can help improve the quality of your code via his refactoring of a bit of example code. This time the focus is on documentation.

One of the first things I look for when I check out code is how is the code organized? Is it laid out well? Is it coded to a particular standard? In our code sample, the first thing we should address is how does the code look. There are a number of suggestions I would make immediately.

His list includes four suggestions for/comments about different areas of his example code:

• There are no DocBlocks or clear coding standards
• Examining The Properties (comments of the class properties)
• Conditionals (changing inline to braced)
• Improving The Constructor (to make it more flexible)

On his code-diesel blog Sameer has posted a tutorial that introduces you to the PHP_CodeSniffer library and some simple examples of it in action.

A coding standard basically tells developers in what style they must write their code. If programmers work in a team than a coding standard ensures that each will be able to read the others code without any effort. [...] A tool which scans your source code and checks it against a standard would be quite a help. PHP_CodeSniffer is one such tool.

The PHP_CodeSniffer package allows you to check code (to "sniff" it) and ensure that it matches against a certain format. The tool doesn't do any testing outside of that, though - no unit testing or functionality checking.

Sameer includes a guide to getting the tool installed and using it to get the source files in a certain directory. He also points to a tutorial for developing your own coding standards.

In a new post to his blog, Jim Plush talks about why he made the choice to go with the Zend Framework over other framework options for his company (Panasonic).

At Panasonic like most large companies we have a plethora of websites ranging from little one off reporting sites to full scale applications. A major problem arises when these sites are left up to the discretion of the developers to choose their own styles, languages and frameworks(mostly custom to themselves). [...] This was where we were 7 months ago. During that time I've been developing a Zend Framework based application that will house all these sub-apps as "modules" underneath the main Zend umbrella.

He lists the reasons why he chose Zend's framework offering - it has the strength of a company behind it, its flexible, its proved its stability, the small footprint and the copious amount of documentation that's been worked up. He also points out a few things that can help keep his development (and, really, anyone's) on the "straight and narrow" - code reviews, a code inspector and unit testing.

Over on the Blue Parabola blog Matthew Turland recently posted a new tutorial on using the PHP_CodeSniffer PEAR package to check out how well your code adheres to the coding standard of your choice.

For the sake of consistency [on a client project], the development team had stuff with the coding standard used by the framework itself. However, evaluating the code manually is tedious and time-consuming. There's a solution to this type of problem: the PHP_CodeSniffer package from PEAR, which builds an infrastructure around tokenizers for PHP, CSS, and JavaScript and utilities to detect coding standard violations within code in any of those languages.

He includes an example token output (the codesniffer package is based on the Tokenizer) from a script and walks you through the initial setup of the package, how to create "sniffs" for the code you want to analyze and how to run them using the popular unit testing tool PHPUnit.

On the Blue Parabola blog Matthew Turland has written up a post about a PHP something that might need a bit more love - the Standard PHP Library.

If any PHP extension is underrated, it's probably the SPL (Standard PHP Library). From what I can tell without having been involved in its development, its purpose is somewhat similar to the STL. A while back, it was useful mainly for allowing class instances to be iterable and simulate array access. [...] Using the SPL classes actually turned out to be pretty straightforward once you got your hands on a good starting guide or two to help you beat the learning curve.

He mentions a few of the things offered by the SPL like the SplFixedArray/SplFastArray, Iterators, SplDoublyLinkedList, SplStack and SplQueue (among others). He also includes some benchmarks running standard code (like normal arrays) against a SPL counterpart - the SPL side beat the normal side hands down. Check out the full post for all of the numbers and comparison types.

In a recent post to his blog Eric Reis talks about "why PHP won" in his web application development over other (web scripting) languages:

Some of them are probably still cursing my name, because - let's face it - PHP can be pretty painful. As a language, it's inelegant. Its object-orientation support is "much improved" - which is another way of saying it's been horrendous for a long time. Writing unit tests or mock objects in PHP is an exercise in constant frustration. And yet I keep returning to PHP as a development platform, as have most of my fellow startup CTOs. This post is about why.

He includes four things (that would be needed to counter the information cascade that PHP has) a "new challenger" language might need to burst PHP's bubble.

• Speed of iteration (a good write/test/debug cycle)
• Better mapping of outputs to inputs
• A similar standard library
• A better OOP implementation

He gets a bit confusing in there, moving back and forth between "PHP is good" and "PHP is bad" comments but he does come back to the one thing that everyone can agree on - regardless of your personal bias, you should always consider this: "it's all about picking the right tool for the job".

Continuing on his his series looking at improvements in the upcoming PHP 5.3 release, Johannes Schluter uses this new post to look at some of the new data structures their update will have to offers in the Standard PHP Library.

In the programming world there are quite a few well understood and explored data structures. Which are commonly used in tons of applications, still the only things PHP offered till 5.3 in regards to structuring data were arrays (more precise: hash tables) and objects. So people had to either abuse them for other structures or implement the structures themselves on top of these. Thanks to Etienne things now are changing and PHP's Standard PHP Library (SPL) extension will offer quite a few standard implementations of data structures.

These new data structures are SplDoublyLinkedList, SplStack, SplQueue/SplPirorityQueue, SplHeap/SplMinHeap/SplMaxHeap and SplFixedArray. He explains a bit of what they are and more detail on one specifically - SplFixedArray.

Jani Hartikainen has followed up on a post from David Otten about standard classes in PHP and how they provide the base for much of what the language does.

David Otton posted a short but thought-provoking post about stdClass, which many think is the "base class" all PHP classes automatically inherit from. I have to admit that I had this misconception as well. [...] This [difference in PHP from other OOP languages] presents some room for analysis in how things are handled in dynamic and static languages, and how those differences affect things...

Jani talks about dynamic and static typing in languages and how that effects the base types things are extended from as well as some of the benefits that having a standard base class affords developers.