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" .

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.

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.

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.

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.

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.

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.

"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

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.

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.