Larry Garfield has posted the results of some of his research into popular PHP frameworks and projects and see how they handle their structure as it relates to the PSR-0 standard.

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

The projects he looked to for his examples were:

• CakePHP
• Symfony2
• Silex
• CodeIgniter
• Zend Framework 2
• Composer

Fabien Potencier has posted the seventh part of his series looking at how to make a custom framework on top of the components from the Symfony2 framework. In this part of the series he improves his basic framework by adding some namespacing to organize the application a bit more.

If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request. As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

He puts the main front controller in just the "Simplex" namespace but adds in others for the controllers and models. He also updates his Composer configuration to create some PSR-0 autoloading.

Chris Hartjes has a reminder posted to his blog today in the form of this recent post that "scope is not a mouthwash" - personal experience from his recent development where he forgot about something as simple as scoping (and it caused him all sorts of headaches).

For [a chapter in my book on dependency injection] I am using Pimple, an incredibly small but effective dependency injection container. Easy to use, simple and effective documentation, just what I was looking for. I also noticed that Pimple supported the use of closures (or anonymous functions) as a way of storing a dependency. Then things got stupid.

He shares a bit of code showing how he added it to his bootstrap but was given a "cannot find class" error when he tried to use the tool. He walks through the steps he followed to track down the problem - looking closer at Pimple, investigating closures and, the ultimate problem, namespace scoping. He was missing a "" to start his namespace and closures work slightly differently:

So why does it behave differently inside closures? I am not 100% sure, but if I had to make an educated guess I would say that when trying to resolve namespaces inside a closure, the interpretor doesn't assume that it is already inside the global namespace, that it is in a namespace of it's own.

One of the features that's recently been introduced into the PHP language has been a feature for keeping code not only more organized, but more modular - namespacing (PHP 5.3+). In this new tutorial from PHPMaster.com they introduce you to this handy feature and include a bit of code showing their use.

Namespaces were a long awaited feature in PHP. While many other important features were released with PHP 5, namespaces were not supported until version 5.3. This led to various techniques for emulating them which, though necessary, were messy and confusing. Although namespaces have been part of PHP for over a year now, such techniques still exist. Many developers simply don't know how to use proper namespaces in their code. In this article I will explain why namespaces are important and how you can use them in your own PHP code.

He starts off by talking about what namespaces are and how they can be used to segment up applications, especially larger ones, into more manageable chunks. Basic code is included showing how to implement a namespace, referencing items inside a namespace, the "use" keyword and the __NAMESPACE__ magic variable.

On PHPBuilder.com today there's a new article from Jason Gilmore introducing you to namespaces in PHP 5.3+ development. Namespaces make it simpler to separate out your code into functional pieces and help keep it organized.

The inclusion of namespace support within PHP 5.3 effectively brought the need for gripes and workarounds to a halt, however adoption of this exciting new feature has seemed surprisingly slow in the more than two years since its release. [...] The utility of this new feature is simply undeniable. Therefore I thought it would be worthwhile to offer a formal introduction to namespaces for the benefit of those PHP developers who haven't yet had the opportunity to investigate the topic.

He starts by introducing the concept of a "namespace" as a sort of container for your code, providing separation that prevents errors like the infamous "cannot redeclare class" issue. He includes examples of PHP's namespace syntax to split out two "Account" classes into two different sections. Using them is as easy as referring to them by their namespaced "path" or using something like the "use" keyword to reassign it to another name.

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.

RubySource.com has posted another in their "confessions of a converted PHP developer" series (more here) with a new article comparing namespacing between the two languages.

The moment you start writing code that grows beyond a few classes, you start to realise that you need a way to group files and logic. While this is easy to do, it can become quite difficult to ensure that you have class names that are unique and don't end up accidentally clashing with other classes in your own code, or classes in other people's code that you are using.

He talks about PHP's namespacing, a relatively recent addition, and how pre-5.3 "pseudo-namespacing" was done through class and directory names with autoloading. He compares this to Ruby's module support that provides a sort of built in namespacing support. He includes a multiple namespace Ruby example and shows how to nest modules for even more fine-grained separation.

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.

In a recent post to his blog Fabian Schmengler looks at mocking something in your unit tests that could cause problems in certain situations - needing a specific kind of response from a built-in PHP function. In his case, he shows how to mock time to return the same formatted date.

A common problem in Unit Testing in PHP is testing something that depends on the current time. For a determined test it should be possible to set the time in your test script without really changing the system settings. In this article I'll describe how it is usually done with OOP and then come to an alternative solution with much less code that makes use of the new features in PHP 5.3.

He shows a usual approach using dependency injection and a class wrapper to handle the set and fetch of the date value. His alternative uses namespacing to redefine the internal PHP function into something custom. Then, when the test is executed, it can use that custom namespace's version, overriding the default. It's a pretty seamless option and can save you a good bit of time and hassle with other classes each time you need to customize the results.

In a recent post to the "PHP and Me" blog they look at how to type less $this in your PHPUnit tests using some handy tricks and a bit of custom code.

Lately I've been writing a few tests (using PHPUnit), and when you do there's one thing you end up doing a lot, which is typing $this-> whenever you need to do pretty much anything. It's not that bad (and PHP can be quite verbose itself) but it can become a bit of a bore I guess, especially after a while. [...] Those were valid points [about the global testing functions added to PHPUnit], and for a while that feature was even temporarily removed. So.. now what? Back to typing all those $this-> over & over again? Maybe not.

The post shows how to use the included functions to remove the "$this" in something like "$this->assertTrue()" or, to reduce things even more and not pollute the global namespace, a different approach by extending Assert. A few code examples are included as well as the class that extends the normal Assert functionality PHPUnit provides. It allows for the more flexible short-hand function calls to automatically be mapped back to their "more correct" versions.