I have done a few tweets in the past weeks hinting at wanting to create a set of common interfaces for things like logging, caching etc. Now I pondered this some more and there are a couple of problems which I am not yet sure how to overcome them. Obviously the goal would be to make it easier to drop in components from one library/framework into another. If you want to see a concrete case where such interfaces could help just have a look at the recently created Doctrine Search project which needs anHTTP client.
So one problem is that it just feels strange to have these interfaces flying around as separate repositories. Of course this can be solved by eventually bringing them into PHP core itself. Until then they could be provided similar to how PHP_Compat provides forward compatibility. That being said I again want to stress that I think these interfaces should be first defined and tested in user land. If the interfaces do not make it into core, they could simply also be copied into the various projects. After all these interfaces should not change often. So first problem sort of solved.
Another issue is that not all frameworks are using PHP 5.3 yet, for example CakePHP 2.0 was just released targeting PHP 5.2. One solution to make things compatible would of course be to place these interfaces into the global namespace. However this runs the risk of collisions with PHP. So another approach could be to simply let those older frameworks "namespace" using the old PEAR style naming convention. Of course this would still prevent real compatibility between PHP 5.3 and PHP 5.2 frameworks. But it would at least help that the API's would be fundamentally the same, making it easier to write adaptors and also ensure that eventually things could grow together.
Now the third problem is much bigger. Most frameworks these days are using PSR-0 for autoloading and class naming, which is great. The reason why adoption is so good is that PSR-0 is already fairly old and. It always takes a while until frameworks can actually adopt these kinds of standards. Right now this time quite long as we just had a flurry of new major versions: FuelPHP, CakePHP, FLOW3, Symfony2. Of course there are still other frameworks that are not stable yet like Lithium and Zend Framework 2. Now if we start to talk among all of these frameworks I am guessing that it will be quite unproductive since all the frameworks that just went stable will likely want to push their specific method names.
Of course they could also add adaptors or simple duplicate methods, but who wants to do that if that means your framework gets more ugly while the other frameworks don't need to change anything? I have not really studied the various interfaces of the stable frameworks, let alone those of the non stable ones. Maybe we get lucky, but more likely we will run into minor differences. So this could be the killer for the entire idea and so in the end maybe the only solution would be for one framework to try and come ahead by convincing other frameworks and application to simply adopt theirs. My personal favorite Symfony2 seems like in a strong position to come ahead in this area given how many libraries and frameworks are adopting Symfony2 components. But it feels iffy to try and compete on interface adoption. We should compete for implementation adoption!
