Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.

In a new post to his site Tom Butler gives some reasoning as to why he thinks PSR-0 is shortsighted and some examples of a possible better alternative.

A little background for those unaware of what PSR-0 is: There's a self-declared PHP "standards" group called PHP-FIG attempting to push several "standards" throughout the PHP community. [...] I have little interest in debating the politics behind pushing standards or whether small groups of developers trying to make decisions that affect the entire community is good or not, but I do object to the PSR-0 standard itself. My issues are purely practical, PSR-0 reduces flexibility and makes life more difficult for developers

While he likes the idea of a standard way to be able to include third-party libraries that can be reused in multiple systems, he suggests that it answers the wrong question. In his view, it should be up to the library/tool developers to ensure the structure of their code to work with a standard, not the other way around. He points out that a "standard" is something that should apply to all situations and some of the workarounds that are needed for PSR-0 negate this idea.

In his alternative method, he suggests an "Autloadable" interface that can be implemented by the library/tool that includes a "load" method to handle the actual class loading. Then this autoloader would be registered via a json configuration file for the package. This allows the developer to control the loading and place any exceptions they might need into their own logic instead of trying to work around possible issues with the PSR-0 loading scheme.

PSR-0 is a bad solution to a good problem. If you take anything from reading this post, remember this: If the standard defined how autoloaders could be extended, rather than how autoloaders worked, then each library or vendor could provide its own extension to the autoloader and everyone would be happy.

On NetTuts.com today there's a post that talks about applying the PSR formatting to your application's code. If you haven't already read their introduction to the PSRs, it's highly suggested.

In a previous lesson here on Nettuts+, you learn about PSR; however, that article didn't detail the process of integrating that coding style into your projects. Let's fix that!

They briefly recap the main two PSRs (PSR-1 and PSR-2, but no mention of PSR-3 the logging interface) and show code examples of them being applied. They also point to the PHP_CodeSniffer tool that you can use to keep your code in the correct structure. Instructions are included to install it specifically for the Sublime Text 2 editor via package control. It's just a command-line tool, though, so it could be integrated with just about any other editor/IDE out there too.

In this new post Patrick Allaert offers a solution that can help speed up the inclusion of files via the Composer autoloader (in addition to the already present "optimize-autoloader" option).

The problem with the classmap strategy and the nature of PHP is that there is no (easy) way to have a persistent variable across requests containing the classmap. [...] This [large returned array of mappings] can even take a big portion of your request's response time when you have hundreds or thousands of classes like it is the case with eZ Publish 5 being based on Symfony, where about 2 600 classes are involved.

He suggests something that could be included into the Composer functionality itself - creating symbolic links in the PSR-0 standard to the location of the files to make it easier for Composer to resolve their location (based on namespace, not having to find them). Some sample code is included showing an additional autoloader that then uses the vendor names to match the path directly.

In this new post to his site Jeune Asuncion shows how he integrated several technologies to make for a robust system - Zend Framework (1.11), Doctrine 2 and the Symfony dependency injection system.

Last week, I blogged about looking for a new application framework to use and more importantly the key things that I would want in one. After reading about the Zend framework, Symfony and Laravel and finding myself hesitant to use any one, I thought to myself why not get the best of each framework? So that's what I did.

He shows a bit of the code to get them to all play nicely together using the Zend autoloader to register the other namespaces and creating a Symfony DI container inside of the ZF Bootstrap and providing it as a resource. You can find more of the source involved in the integration on his github account.

In his most recent post Anthony Ferrara takes a look at autoloading - mostly asking the question of whether the problems it has really outweigh the benefits.

The real problem that autoloaders solve is to load dependencies. [...] The normal logic that's used to justify autoloading over manual dependency loading in production is that it only loads the classes you need. Therefore you save the parsing costs of classes that you don't need. But surely that additional run-time loading has costs. So I decided to setup a test to see how expensive that additional run-time loading costs us, and to prove whether or not autoloading is worth it in production.

He gives an example of the two methods - using the spl_autoload_register method to define a loader and loading them with a defined file path instead. He found the autoloading version slower than the hard-coded (by quite a bit) but how, when the number of files is reduced, the performance gets much closer. He also briefly looks at two other pieces of file-related functionality: file_exists and require_once.

On PHPMaster.com there's a new tutorial that shares some useful PHP snippets that you could use in your development.

"X PHP Snippets" type articles abound on the Internet, so why write another one? Well, let's face it… the PHP snippets in them are generally lame. Snippets that generating a random string or return $_SERVER["REMOTE_ADDR"] for the IP Address of a client really aren't that interesting and are of modest usefulness. Instead, here's five snippets that you'll no doubt find interesting and useful, presented along with the problems that inspired them. I hope the creativity in many of them inspire you to write better and more creative code in your own day-to-day endeavors.

Their "five tips" are about:

• Generating CSV files from an array of data
• Autoloading classes (in a PSR-0 way)
• Parsing data with the unpack function
• Templating in HTML (creating a "View" object)
• Using file_get_contents as a cURL Alternative

In this new post to his blog Charles Spraggs takes a look at the Zend Framework 2 and talks about how to handle the configuration of the application and of your modules.

As ZF2 increases the beta count and draws nearer to RC I've noticed more questions popping up in IRC regarding configuration. Questions like: "How do I setup XXX?", "Where do I add module options?" So, I decided to write up a quick blog explaining how configuration works in ZF2. By default, there are three types of configurations.

He points out each of the three places and mentions what goes in each (main config, module config and autoload config) and gives a high-level overview of the load order for the modules in your application - merging the configurations then using a "glob" to figure out the correct config settings to use.

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.