Alessandro Nadalin has a new post to his blog looking at the Composer project and using it to manage packages and dependencies in PHP applications.

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.

Matthew Weier O'Phinney has a new post today talking about why namespaces in PHP matter and why he thinks they're a valuable contribution to the language.

You've heard about PHP namespaces by now. Most likely, you've heard about -- and likely participated in -- the bikeshedding surrounding the selection of the namespace separator. Regardless of your thoughts on the namespace separator, or how namespaces may or may not work in other languages, I submit to you several reasons for why I think namespaces in PHP are a positive addition to the language.

He breaks down his reasons into four different categories - the code organization benefits that come with namespace "containers", simplified interface structure, improved readability (no more huge class names) and a simpler method for identifying dependencies

Sebastian Bergmann has announced the release of the latest version of the popular PHP unit testing software - PHPUnit.

Among the features introduced in this new version, the most notable are the support for test dependencies and fixture reuse as well as the possibility to run tests in separate PHP processes for increased test isolation. Please have a look at the ChangeLog for a complete list of changes.

As a teaser, he also mentions the work being done on the code coverage features that will be included in the next release.

In a recent post to his blog Evert Pot warns against some of the issues that mutual dependencies in your applications.

Much like most people, I try work out my class dependencies through a top-down 'waterfall'-ish approach. By attempting this, I think allows me to keep the structure very clear and understandable. [...] I try to apply the same model to instantiated objects and packages (groups of classes). When an object encapsulates another object, I attempt to make sure the sub-object object is not aware of the parent. When I design packages, I attempt to make sure 2 packages don't require 'each other'.

He gives an example of where this could cause problems - a Database logger that has three types of logging included: file, syslog and database. Obviously the last of the three requires the Database class so they must always be used/included together.

As a bonus a database-error could occur while logging, resulting in an endless loop (or segmentation fault if you're using PHP). [...] However, these types of situations are sometimes simply unavoidable (that's why we have include_once). When they are needed, they should be implemented with care and consideration.

Sebastian Bergmann talks about a new bit of functionality he's put into the 3.4 release of PHPUnit (the popular unit testing tool for PHP) based on a suggestion from a paper he'd read:

Back in July, I came across an academic paper (more academic papers on testing that I read recently) titled "JExample: Exploiting Dependencies Between Tests to Improve Defect Localization". [...] For the upcoming PHPUnit 3.4 I have implemented support for the idea expressed in the paper mentioned above.

The feature is a system that helps localize problems at the source, stripping away all of the cascading issues it might have tripped off, causing other tests to fail. This new feature (as illustrated by his code example using a DependencyFailureTest class) makes it simple to fail a test immediately whenever the scripts needs to via a fail() method. Check out the full post for the rest of the code and some further explanation on how it works.

Jani Hartikainen has made a few updates to his packageizer script for the Zend Framework to improve its interface.

Now, based on some feedback from users, I've improved the user interface of the tool: You can now select multiple items for inclusion in the package, and I've made it possible to get the packages in .phar format. It also has initial support for different libraries, ie. Zend Framework 1.6 and Zend Framework SVN trunk, but currently only 1.6 stable is available.

The tool allows you to select just the packages out of the Zend Framework that you might want to work with and packages them up, along with their dependencies, into a simple, portable file that can be used anywhere the Framework normally could.

Jani Hartikainen has put together a handy script for those out there that like what the Zend Framework is all about but don't really need the whole thing to get the job done. If that's you, this script might be just what you need.

Did you ever want to use just a single component from Zend Framework, but couldn't figure out which files you needed? Well, here's a solution: Zend Framework packageizer script! Just pick the class you want, and you'll get it and all its dependencies in a nice zip file for you to consume.

The packager uses the tokenizer functionality PHP offers natively to look through the files for the package you're after and finds all of the files that might need to be included and pulls them right along into the zip file.

Helgi has posted about an update to the next alpha release of PEAR to remove support for certain versions of PHP:

For the next alpha release of PEAR that will happen in 2 - 4 weeks we'll have a min dep of PHP 4.4 and 5.1.6, so basically excluding 5.0.0 - 5.1.5 Now why am I going to do that?

This pushes more people up from the PHP 4.3.x series (to the 4.4.x that was the last PHP4 release) and up to a more recent PHP5 version for the future. Eventually, PHP4 support will be dropped all together, but for now there's a bit of a hold out.

On the SitePoint PHP blog today, Troels Knak-Nielsen has written up an article that talks about dependencies in your applications - those little interconnections your code relies on to do more with less.

In lack of better words, I'll call this compositional programming style. It's a style which is usually more prevalent with experienced programmers. [...] There is, however, a dark side to composition - dependencies.

He starts with a definition to bring everyone up to a level field then moves on to how their used (through a "global symbol" or directly passed in) and how they can "leak" if you're not careful.

To help protect you and your code from any kind of damage down the line, Troels suggests making a container to keep objects where they need to be. He even includes an example with namespace support to make things even easier down the road.

Over on the ThinkingPHP blog today, there's two new tutorials from Felix Geisendorfer - one dealing with the conversion of WordPress titles into the "slugs" the system uses, and the other the first article he shows a method how, inside the structure of CakePHP, to make a component to grab the slug out of the URL and parse it down to the different parts of the title.

In the second, Felix demonstrates how, with some simple if logic, you can simulate dependencies. His examples include a simple if to check for the return of "true" from various functions and an inline example of an svn export and FTP.