Bradley Holt has announced the creation of a new proposal Zend_Container, a simplified version of Zend_Di. According to him, if the framework is going to have a dependency injection component this component needs to be as simple as possible, something along the lines of PicoContainer.

The proposal seeks to replace the use of class-managed singletons and Zend_Registry, scope access to containers and use reflection to determine dependencies for items inside. The component has been given the go-ahead from the ZF team and development is already in process.

Among the standard object oriented principles is favouring composition over inheritance, and there are plenty of design patterns that work along this line. However, one of the most useful day-to-day facets of the idea doesn't seem to get a lot of attention from PHP developers, namely dependency injection.

The general idea is, that if your class depends on some other object, that object should be passed in rather than generated internally or retrieved via a global variable or singleton.

He shares few ideas on how you can use this method in the controller of a Zend Framework including the use of the Zend Registry and an Action Helper. Code snips are provided for reach to show you how it'd be done.

Anyone crazy enough to help out is more than welcome. I'm currently working on the GTK dependency stack, which will hit quite a few PHP dependencies and PECL extension dependencies in the process. And yes I'd love to submit my hacks/fixes upstream, if someone could find me some information (where do you send libiconv patches?)

Her post mentions some of the things she's already been working on to help further the cause - compiling various Open Source libraries, figuring out issues surrounding MiniGW and some examples of more complex dependency issues she's come across.

While each of these [PEAR Mail, PhpMailer, SwiftMailer, Zend_Mail] will work with Solar, the new Solar_Mail and Solar_Smtp packages work "natively", in that they support automatic configuration, locale and exception inheritance, and so on. Read on for some examples on how to use them.

In his example he sets up and sends a simple message, setting the contents of the email (sent as an HTML message). Since there's been much talk about the safety of a lot of the mailing systems in frameworks, Paul talks about how it's been secured from header injections, through safe attachments, and from a transport dependency-injection for SMTP.

There's even a method included that lets you take the SMTP information out of the script and put it into the Solar configuration file to use in the entire application.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

Recently, a curious bug was opened at pear.php.net for the PEAR package (#9639). In it, a user was able to uninstall the Structures_DataGrid package, even though all of its subpackages were installed, which should have prevented uninstallation.

There's been a key update to the dependency module that keeps this sort of thing from happening, but it's only in versions 1.4.5 and higher. Greg also recommends the reinstall of any packages that you've installed before and up to version 1.4.4 just to ensure that the dependency database is up to date.

The resulting SVG is generated through GraphViz. He just ran the script on the eZ components.

It's a bash script that can run local to the machine and make the images as it speeds through your PHP code. Jakob mentions that the script it free for all, and offers a direct download from his page. You can see a more full-size example in the current graphs of the eZ components trunk.

I installed PHP 5.2 on one of my testing servers today and a couple of bits of code that previously worked fine in version 5.1.6 threw fatal errors in the new version. The error message was "Nesting level too deep - recursive dependency?" and it took a little time to track down the root of the problem. Here's what I'd done wrong.

Basically, his problem was using the "non-strict" evaluation for checking if two objects were equal to each other (== instead of ===). This compares everything about them, down to the properties - even if they're references to other properties inside of the same class (which is where the problem lies).

So, the fix is simple - === instead of == when comparing those objects. You'll be happier for the change.

Because it makes great use of dependecy injection, Solar has a standardized form of generating/retrieving dependency objects using its Solar::dependency() method.

The callilng code sends the dependency params to the target object at construction time. The target object then passes those params through Solar::dependency() to retrieve or create the dependency object.

Paul also briefly mentions that the parameters passed in can be: an object (including the dependency object itself), a string, or an array (treated internally as parameters to create a new object).

The June issue of PHP Architect is out. My column this month is on dependency injection, a topic which I've been warming up to lately.

First there was CORBA. Then insane complexity of CORBA was supplanted by the intolerable complexity of EJB. Influenced by an agile mindset and the power of Unit testing, a group of java programmers began to construct simpler alternatives to EJB. Thus, the inversion of control frameworks were born. Martin Fowler came along, clarified and renamed the pattern dependency injection. This activity has originated in the Java world, but the pattern applies in PHP as well.

It is heartening to see an industry solve a problem over the course of a decade, moving from complex vendor driven middle-ware to simple patterns. The thing I like most about DI is how dead simple it really is.

He goes on to say that Fowler's article on the topic is a "must read" for anyone who will even be looking into dependency injection. He also mentions two issues he has with most of the other introductions - the examples they use and the "over-emphasis on the container".

His goal in writing this month's column was to help to avoid some of those problems while still keeping it relevant and easy to understand.