In a recent post to his site Herberto Graca shares some of his thoughts around packaging and namespacing and how it relates to the overall architecture of your application.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems: components, relationships between components [and] principles guiding the design and evolution of components and relationships.

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

The post then goes on to talk about "spaghetti" architecture, what makes for a more maintainable codebase and how this impacts the overall structure. He shares a few of the "packaging principles" previously defined by Robert C. Martin and the concept of "screaming architecture" (it should be very clear about how it's structured).

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.

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.

The results of the latest International PHP Magazine are in and posted today on their site. The question this time was asking developers and visitors alike what they think sucks about PHP.

Choices included "No lexical scoping", "PEAR", and "Worst Configuration System" but one climbed to the top far above the others - "No namespacing". Trailing that at a distant second were two, getting the same number of votes - "No lexical scoping" and "Can't afford a vowel" (hmm, interesting).

Up for this week is a new poll that asks those out there that have used the Symfony framework to cast their votes about what they think is the best feature the project has included. Check it out and cast your vote today...

The results of the latest International PHP Magazine are in and posted today on their site. The question this time was asking developers and visitors alike what they think sucks about PHP.

Choices included "No lexical scoping", "PEAR", and "Worst Configuration System" but one climbed to the top far above the others - "No namespacing". Trailing that at a distant second were two, getting the same number of votes - "No lexical scoping" and "Can't afford a vowel" (hmm, interesting).

Up for this week is a new poll that asks those out there that have used the Symfony framework to cast their votes about what they think is the best feature the project has included. Check it out and cast your vote today...