The TutsPlus.com site has posted the fourth part of their series covering the use of namespacing and autoloading in WordPress plugins. In this latest tutorial they take everything they've shared (and made) previously and put it all together into a cohesive whole plugin.

At this point, we've laid the foundation for our plugin, written the plugin, and defined and explored namespaces and autoloaders. All that's left is to apply what we've learned.

So in this tutorial, we're going to put all of the pieces together. Specifically, we're going to revisit the source code of our plugin, namespace all relevant classes, and write an autoloader so that we can remove all of our include statements.

He starts off talking about namespacing and how it relates to directory structure and the code you'll need for each of the plugin files for put them in the correct namespace. With just these in place, however, errors are thrown. This requires the setup of a custom autoloader and PHP's own spl_autoload_register handling. He includes the code for the autoloader, taking in the class name and splitting it up to locate the correct directory, making it easier to replace the loading of all plugin scripts.

For those out there that might have heard comments made about the PSRs (PHP Standards Recommendations) but aren't quite sure what they're about, Lorna Mitchell has posted an introduction to the three currently approved standards.

There's been some cool things happening in the PHP world over the last few years, but with the least helpful names ever ... yes, those PSR-somethings which all do totally different things (apart from two of them which are the same). They're actually all superb things, and done for a good reason, so I thought I'd try to translate them into normal speak.

She goes through each of the three, explaining what they are and how they could affect your applications:

• PSR-0 is for autoloading
• PSR-1 and PSR-2 are for Coding Standards
• PSR-3 is for Logging

There's no code included in the post showing how they'd be implemented but there are links back to the standards themselves.

Ralph Schindler has a new post to his today looking back at a sort of history of autoloading and some of what we've learned even in just the journey from PHP 5.0 to 5.3 (and has become best practice in the community).

It wasn’t until years later that certain best practices had emerged and the prolific usage of require_once/include_once throughout large bodies of code had started drying up. Even after autoloading had been adopted by larger more visible projects, a common patten had yet to emerge. [...] Fast-forward to today, and we see that this standard for autoloading has agreed upon by a large number of projects and has come to be named the "PSR-0 autoloading standard".

He covers some of the things we (the development community) have learned about autoloading and resources in our applications. He talks about the classmap tool that Matthew Weier O'Phinney developed (and some of its downfalls) as well as a move into PHP namespacing that has helped to make some of the "namespacing" based on class names obsolete. He's noticed a pattern in namespacing already - a self-contained structure that provides more of a "drop in" solution and how that's handled in the code.

On the Propel blog there's a recent post talking about how the age of autoloading might be ending and how namespacing could be the next logical step (or could it).

Autoloading in PHP is a great time saver. It lets you write concise scripts without the knowledge of the exact directory structure of the libraries you use. But with the arrival of namespaces in PHP 5.3, and the influence of Java over new generation PHP frameworks, autoloading is changing. In the near future, explicit autoloading will be ubiquitous, but with none of the advantages of the old style autoloading.

He talks about "the old days" when things were included manually through file paths, how that graduated to the SPL autoloading and, most recently, up to namespace autoloading. He shares code samples of how the namespace loading works and how you can abuse it to override current classes/functionality with your own. He points out one interesting correlation though - that the "use" keyword seems a lot like the "require_once" of way back when. He shows how the added verbosity of namespace usage can be a hinderance on frameworks, citing microframeworks specifically and showing one implementation that's non-namespaced next to another that is.

Martynas Jusevicius continues his look at the enhanced features that PHP5 has to offer with this post focusing on the ability to autoload classes that haven't been defined yet.

Continuing the series about useful features in PHP 5, another overlooked one is class autoloading. [...] Basically, you get a class name as a parameter in your __autoload() function, and using it you have to figure out the path to the actual class file and include it.

He includes both a description and an example of some code in action and even points out something that can help to make for cleaner, more organized code - the ability to register more than one autloader with the spl_autoload_register function.

Martynas Jusevicius continues his look at the enhanced features that PHP5 has to offer with this post focusing on the ability to autoload classes that haven't been defined yet.

Continuing the series about useful features in PHP 5, another overlooked one is class autoloading. [...] Basically, you get a class name as a parameter in your __autoload() function, and using it you have to figure out the path to the actual class file and include it.

He includes both a description and an example of some code in action and even points out something that can help to make for cleaner, more organized code - the ability to register more than one autloader with the spl_autoload_register function.