As is mentioned in this new post to PHPMaster.com, the PHP standards group is officially in the voting process on two new standards (PSR-0 being the first) setting up some standard development practices for PHP applications - PSR-1 and PSR-2.

They initially started out as one proposal but the initial round of voting didn't yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.

In the wake of the success of the PSR-0 standard (used in autoloading structures across frameworks and various applications), the PHP-FIG (Framework Interoperability Group) has start on drafts of other standards to help provide some guidelines to standardize PHP development across projects.

Among the group, Paul Jones has been writing serveral proposals under the PSR-1 standard banner that include:

• The basic draft of the standard
• An extended draft of the same
• A more advanced version, PSR-2 that also includes some survey results on various syntax elements.

If you want to know more about the PHP-FIG group, you should listen to this excellent panel interview of the group from the Voices of the ElePHPant podcast. Paul and others get into the point of the group and how the standards are progressing.

Stefan Koopmanschap has a quick new post to his blog with a handy tip for Composer and Cilex/Silex users when dealing with custom namespaces.

For a new proof of concept application I'm building, I need both a simple web interface as well as some commandline tools. I decided to use Silex for the web interface and Cilex for the CLI tools, and opted for using Composer for installing these dependencies into my project. I ran into some issues with the custom project libraries I was building for this application however. Registering my custom namespace into Silex and Cilex didn't result in the classes being loaded for some reason. Composer helped me out though.

His solution involves letting Composer be the default autoloader for the application via an "autoloader" configuration option in the "composer.json" (that can also take a classmap option if you're not PSR-0 compliant, see here).

On PHPMaster.com today there's a new tutorial introducing you to the PSR-0 standard and how it effects the autoloading in many PHP applications and frameworks. Specifically, they show how it's implemented in a Symfony2 component

In this article I'll walk you through the "history of autoloading," from the older to the current PSR-0 standard autoloader approach found in many PHP frameworks such as Lithium, Symfony, Zend, etc. Then I will introduce you to the ClassLoader component from the Symfony2 project for PHP 5.3 which follows the PSR-0 standard.

He starts with a look at a basic "__autoload" function call that looks in a directory for libraries. Improving on that, he makes two methods for loading - one for controllers, the other for models - and a loader that splits on the "_" character and determines the path from there.

Even this isn't PSR-0, though, so he shows how using namespace information, you can load classes in a unified way. He shows how to implement this with a loader that's already well-developed and ready for use - the Symfony ClassLoader component. They show how to register namespaces, prefixes as well as use the APC functionality to manually store/fetch the APC version of the loaded file's opcodes.

In a new post to his blog today Anthony Ferrara looks at the (heated) discussion that's popped up around having the PSR-0 autoloader standard included as a part of the PHP core. He gives his reasons (three of them) why he's not for the decision.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

Henri Bergius has a new post to his blog today about a tool that could help make code reuse across PHP applications a much simpler process. The Composer tool (and Packagist) make setting up packages and dependencies easy.

In PHP we've had a lousy culture of code-sharing. Because depending on code from others as been tricky, every major PHP application or framework has practically had to reimplement the whole world. Only some tools, like PHPUnit, have managed to break over this barrier and become de-facto standards across project boundaries. But for the rest: just write it yourself. But now Composer, and its repository counterpart Packagist, promise to change all that. And obviously new conventions like PHP's namespacing support and the PSR-0 standard autoloader help.

Making a package is as simple as setting up a JSON-based configuration file that names dependencies and package metadata (like name, type, etc). Composer generates an autoloader of its own to handle the loading of your needs based on the dependencies listed as a part of the package. If you'd like more information about Composer or to get the latest version and try it yourself, check out the project's github repository.

In a new post to his blog Lukas Smith has a list of PHP projects that have popped up around the Symfony2 framework and are following some of the framework's standards for development.

Here is a short overview in alphabetical order of libraries that have spawned around Symfony2 (and just to clarify not at all focused on just Symfony2). Common to all of them are that they require PHP 5.3 and follow the PSR-0 for class loading.

Among the tools mentioned are things like:

• Assetic
• Imagine
• Snappy
• Twig
• Sismo

Matthew Weier O'Phinney has a new post to his blog (following this post on directory iteration for autoloading) with some of the benchmarks of different methods he tried for automatically loading the libraries his scripts needed on demand.

During the past week, I've been looking at different strategies for autoloading in Zend Framework. I've suspected for some time that our class loading strategy might be one source of performance degradation, and wanted to research some different approaches, and compare performance. In this post, I'll outline the approaches I've tried, the benchmarking strategy I applied, and the results of benchmarking each approach.

His testing included a baseline of the Zend Framework 1.x series loading, a naming/class standard following the PEAR standards and class mapping with file/class name pairs. He includes his benchmarking strategy and the scripts he used to run the tests (on github here). He ran them both with and without opcode caching to give a better overall performance view.