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 an HTTP 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!
A) Interfaces in the main PHP tree therefore all have to abide or die, that is how Java gets its notoriety. The SPL was a good start
2) Else start something like Apache Commons for Java which is the Switzerland, and allows drag and drop or reference implementations.
PHP needs that kind of dictatorship that Java has in order to move forward.
Just my 0.02
I think the way the http-component in sf2 has been included by major projects was an awesome example how good implementations in the PHP-cosmos are surviving and spreading. We all had to live with those namespace workarounds for years and after a while it took place in the core.
I'm no fan of the "dictatorship" model of the previous commenter and I like the freedom of PHP - even if it takes more time before something is implemented in core.
My suggestion is: do it the component way and setup a sf2 component facing this problem/feature.
Gosh I'm drunk!
My response turned into a blog post: Please Do Not Interface the PHP World
Once again, XKCD hits the nail on the head: http://xkcd.com/927/
I'm not going to comment on whether this is a good idea or not, but I think that what you're suggesting may be impossible this late in the game. How many projects and frameworks would have to change (with many having to become backwards incompatible?) in order to drive adoption of a standard interface. Who decides what the standard interface is? My guess is that each framework community would want its own interfaces adopted and make others conform. Overcoming NIH inertia is difficult.
@Herman: thx for the feedback .. here is my reply, which also turned into a blog post :)
@Josh: Yes, I do not know yet how this collaboration would work in detail as I tried to point out in my blog post.
I believe that a "one true API" is probably not a good idea. However as someone who has come from large (Gigs of source large) application development on various platforms in languages like C, C++, Java, Obj-C and so on I find PHP 'messy'. Multiple solutions result in less people working on each solution, more bugs, less quality, more incompatibility and so on.
Its actually something that affects the whole of open source. You install several apps and often find you need several implementations of libraries that basically do the same thing because each of those apps uses a different library. Then when developing you're own app you find library A does everything except X and library B does everything except Y but it does do X. You either end up trying to patch X in to A or Y in to B or write a new library C.
The skill is getting a balance between authoritarianism and not stifling development. I think there are some areas where defining some standards, interfaces and wot not and getting people to adhere to them *is* a good idea. Writing new code is fun but not cost effective if you can have a system where you plug already written code together.
May be to start some of the existing PHP interfaces (in the language) could be more properly enforced. For example when I took over maintenance of the Direct IO PECL extension I added stream support since it seemed daft that it didn't support PHP streams. Why *are* there several PHP HTML client implementations? Why don't we just fix one of them and stick with it. If the API isn't sufficient lets extend it. But at the moment there's opening an HTTP connection via streams, the PECL HTTP extension and curl.
I don't think it should be an all or nothing. But there are areas we should be getting together, discussing and deciding whether some kind of standardisation is useful or not. Until we do PHP will continue to look a bit amateurish.
Obviously there can never be one true standard unless you change PHP to only allow definition of classes that implement an interface that is bundled in core. But that is obviously not going to happen, nor should it of course.
The idea is to create some interfaces that are bigger than just one framework. Thats all. Its not about stifling innovation, its not about preventing competition.