Update: I mentioned the great merit of the whole PSR working group and highlight @simensen. In no way I want to just say Beau did it all, but just that he helped with his contribution also. PSR whole group of people are hardworking and they deserve credit for bringing us all the interoperable standards. Thanks.
So I know not everybody is familiar with the inner workings of autoloading goodness that has been going on for a while now. Thanks to PRS0, a standard for defining interoperable autoloaders, we have seen an amazing proliferation of development activity around libraries and tools and what not on the PHP world. Composer itself heavily followed upon these standards and seized the opportunity to make libraries totally interoperable such that we can define a requirements file, aka composer.json, and have the tool place packages under directories and basically use the classes inside these directories as if they were in virtual namespaces ready to be used. That gave rise to the new era of libraries truly shared widely, frameworks being split into components and reused across multiple frameworks, the creation of microframeworks from where to use subsets of components from a larger framework, doing more decoupled development, and what not. Most importantly now we are living and walking in a culture of development that is starting to cherish package design know-how and best practices more and more because of the need of FOSS and in-house reuse.
So the group that helped saving the PHP world, if we want to put it that way, is now coming with a seemingly new PSR4 proposal because we are entering the package aftermath era and we want to get rid of duplicated paths like what composer is doing under our vendor folder like: `vendor/vendor_name/package_name/VendorNamespace/PackageNameSpace` -> `vendor/vendor_name/package_name/ClassOnRootPackageFolder`.
This is just more great news! However sometimes in the making of standards people tend to complicate things unnecessarily, not even willingly but because of nuances of text. Thankfully for our community, people sometimes catch interest on writing things and conveying things in a simple matter. I read and tried to understand the specification for PSR-0 which is very short https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md and it kind of makes sense because it is good and simple. I read also the PRS4 proposal and couldn’t really follow on everything. But as I was trying to understand it, I was referred to a brilliant simplification made by one friend. Thanks to @simensen I think we can pretty much understand PRS4 as a slight modification to the PRS0 and be happy and done with it. I will give you the link i read https://groups.google.com/d/msg/php-fig/8ibeZRXsclM/2xsaawOcCqYJ and I am sure you will find your way to the links to read how he simply put a very short and simple text adding some minor constraints to PRS0 and turned it on a very simple extension that we can now call PSR4.
The communities that are interoperable, symfony2 community among them, can greatly benefit from this simplification, because they will read and understand straightaway what is PRS4 package autoloading and what it entails. Pretty much the thing has even a PR ready so it is about just to convey things clearly and simple. If you are like me, jumpy on supporting the symfony2 community efforts, please do reading and :+1: this great effort that I am sure will encourage guys like @simensen among others who are always bringing us goodness to play with.
Cheers! and encouragements in all good!
undeservedly graced to write this, your friend @cordoval