On the Delicious Blog Ian has written up a post with a proposal for WordPress suggesting that it introduce some functionality to help with dependency management and possible conflicts between the needs of plugins.

‘Dependency hell’ is a problem faced by all software, and it has been rearing its ugly head in the WordPress space over the last few years with more and more plugins using third-party libraries of code. [...] The most frustrating thing about this issue is that it’s caused by having the best of intentions! Developers use third-party code to be efficient and avoid reinventing the wheel. The code has been written by others and used and battled tested by many.

The WordPress community has a hard enough time already trying to get onboard with Composer (unlike the rest of the PHP world), without it getting tarred with the wrong brush!

He points out that, while this does have to do with packages installed through it, Composer itself isn't the issue. He offers a few suggestions and what he sees as an "ideal approach" to the problem based on some of the ideas presented here. He breaks it down into four types of code: third-party installed via Composer, Composer packages in core, custom Composer behavior and the idea of "package sandboxing". He includes some of the considerations to make this happen and plans on how the idea can move forward.

In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.

The PHP landscape has fully transitioned into its Package Age™ [...] However, due to PHP's nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.

In his Guzzle example he describes the main problem - when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.

On the Refulz.com site today they've posted a new tutorial looking at the use of traits and how to resolve conflicts and work with method precedence.

In our previous post about the multiple and nested traits, we read how nested and multiple traits can be used in a class. In such cases, there is a possibility of the same method name existing in the trait, and the class using the trait. Furthermore, the same method name might also be present in the parent class of the class using traits. It is important to understand how the precedence order works for such cases.

First they look at the precedence between classes and traits with the class always winning...unless the method is inherited from a parent class. They also mention the order when it comes to using the "insteadof" and "as" operators as a way to get around conflicts between traits.

Christian Schaefer has a recent post pointing out a common frustration among developers of applications with NoSQL backends, specifically with Doctrine, MongoDB and PHP DateTime objects - timezone conflicts.

I really like Doctrines way of dealing with dates and times. Instead of passing timestamps around or strings with ISO date format it simply makes use of the PHP native type DateTime which provides all you really need to work with. PHPs interface to MongoDB however comes with its own MongoDate type which provides hardly any functionality compared to DateTime and it’s not compatible with it. So what’s the difference?

In some of the comments to the post, readers mention that the problem is bigger than just the tools used to work with the database, it's that databases usually don't care about timezones when working with date/time. There's also an interesting mention further down about the timezone support MongoDB does have and an example snippet ofo code that uses the support.

Josh Holmes has a new post to his blog today with a tip on resolving version conflicts while developing PHP applications on an Azure installation.

A little while back I wrote a blog post titled Easy Setup for PHP On Azure Development. One of the things that I touched on is the PHP version conflicts. I had a much better idea which I’ve tried and have working so I thought I’d blog that here. What I had you doing in the Easy Setup for PHP On Azure Development is renaming the directory for PHP from something like C:PHP or C:Program FilesPHP to something else so that it wasn’t in the %PATH% so there wasn’t a conflict.

You don't have to do it this way, though - there's another option that involves editing the web.config file on the Azure side to tell wit there the correct PHP install lives. He also explains how you can test your WebRole code locally instead of having to upload it each time by setting up a virtual directory in your project.

In reference to some comments made on the previous post ("Comments Considered Harmful") to the PHP in Action blog, there's a new post explaining and responding to some of the things said by visitors.

Conflict is not a bad thing. That is, if it leads eventually towards clarity and understanding rather than confusion and misunderstanding. [...] A debate about a technical matter may be conducted in parallel with an altercation that addresses the relationship between the participants. This is confusing in itself. Keeping these discussion apart will help maintain clarity.

Using this tact, he responds to the criticism made on the previous post, specifically one that points to this article as to why "considered harmful" articles should only be seen as fodder for argument and should be "considered harmful" themselves.

Tobias Schlitt has posted some comments on things recently said on PHP's upcoming support for namespaces - specifically on the ideas about naming classes the could conflict with PHP's own internal ones.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

After hearing Stefan Priebsch's talk at this year's Dutch PHP Conference, something occurred to Derick Rethans - there was a small sort of issue with using namespaces and possible future PHP's own namespace.

One of the things that came up is the conflicts that can arise with internal classes. In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working

He offers a simple solution that can prevent this sort of conflict for the future - defining your "use" and then creating a new instance of the namespace into a variable instead of just an "as".

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

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.

Following right on the heels of a different PEAR problem, Greg Beaver has posted about a similar PEAR-related issue that could cause some serious problems for you and your installation.

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.