In my previous blog post I was brainstorming the possibility of collaboration between various frameworks to define a set of common interfaces. But I kind of failed to explain why this would be useful. Herman's "rebuttal" made this omission on my part quite clear. He and other critics of this idea pointed out that PHP's success over Java in the web world should be seen as an indicator that standardization efforts stifle innovation and slow down development. I totally see where this view point is coming from, but believe that they are looking at certain facts and come to the wrong conclusion. That being said the open questions left in my previous blog might still prevent this idea to take off, even if I manage to convince the general community that the above mentioned negative effects are not such a significant concern.
First up its clear that PHP has done more things right than wrong. The success is the best proof of that. But change is inevitable as the web is still in its infancy on so many levels and the requirements and expectations steadily increase. The challenge here is of course not abandoned the strengths as we search for solutions to these new challenges. PHP has always taken very pragmatic approaches, whereas Java seemed to rather ponder everything to oblivion. But what has also become apparent to me is that this long phase of deliberation that Java affords itself actually leads to really good standards. What is causing Java all this pains is that it takes them 5 years to go through this entire process. On top of that I think they are suffering from an overly verbose language and often overly complex infrastructure requirements. However to me the conclusion here is that once these guys have spend 5 years to figure out a standard it takes us much less time to adapt the concepts to PHP and this makes us stronger: It allows us to combine pragmatism with clean well designed architectures.
Of course there will be those that dispute if Java standards have indeed have a positive effect on frameworks such as Symfony2 and Zend Framework 2. Of course pragmatism also means that you can choose to ignore the standard interfaces if you feel they are constraining you too much in your quest for innovation. As a matter of fact I would be quite surprised if all developers and frameworks would adopt interfaces defined inside PHP core. So choice will remain.
However there are many different ways to innovate one is innovating on the API. But the imho much more relevant one is innovating on the implementation and surprise here interfaces actually help! Without common interfaces if you come up with a better implementation for an exiting API, there is no way to easily introduce this into existing code bases because for various reasons most frameworks are using "type hints" (I hate this terms, they are not "hints" .. but I digress). So only if there are common interfaces can an other innovate on implementation without having to face a huge up hill battle in having to displace the current implementations which are already part of a larger code base.
Furthermore there is also a very practical consideration with common interfaces: It encourages using the best tool for the job. Take the example of Doctrine Search I mentioned in my previous post. If there is a common interface for HTTP clients then it would make it possible for Zend Framework 2 users to keep using their HTTP client, which they are potentially already using in their application. While Symfony2 users who seem to lean towards Buzz can continue to use their HTTP client. Finally those who use neither could still be provided with a simple bare bones implementation as part of Doctrine Search. Furthermore those users with very special requirements (performance, routing or whatever) could implement their own HTTP client. Here I am starting to circle back to the argument that common interfaces help in "implementation innovation".
Anyway, I am still in brainstorming mode here. So I very grateful for any feedback on the pro's and con's of defining common interfaces and of course also in how we can practically establish such interfaces if we find them useful for PHP as a community.
Here's my $0.02...
I agree, it would be cool to have a standard which could be adopted by frameworks. But, as stated, that ain't gonna happen.
So, just as so much in PHP is optional, let's build a standard framework feature into the core. An extension perhaps.
This standard could then be adopted optionally, and more importantly, extended upon or even mixed it to an existing framework.
I'm thinking of it like strict mode. If you've got it turned on, your shit better be straight. Same thing applies here. Maybe this mode enables stricter type checking or mandatory constructor arguments. Anyway, you catch my drift.
Kinda funny, the only thing I could really think about when reading this post was this: http://xkcd.com/927/
I would welcome these interfaces in the SPL, so that you do not have to wonder about copying them in every project/framework. Even a simple Request/Response interface would be great, after all HTTP does not change very often.
The problem I'd like to solve with these interfaces however is the diffusion of object-oriented programming in PHP without the need for frameworks to wrap every native function in classes. Only PDO is strictly object-oriented.
Request/Response is actually where I am already not so sure if there should be an interface. In Symfony2 we decided not to, because its really a data container for the most part ..
From how i understand lukas, the idea is not to have an "interface for frameworks" but really a set of interfaces for clean decoupling of standard features.
there is a serious not-invented-here problem with many php projects - and on the other hand a lack of easily usable components for standard tasks. compared to the java world xkcd is joking about, there is no standard at all in php, just zend and ez and some others. while of course competition is necessary and your important components won't be covered by the generic api, i strongly doubt that every project needs its own logging implementation.
if we manage to abstract such things so that frameworks and applications can focus on their core business, this is really a help for actual innovation and not a problem.
just for example: for node.js this is working out great.
just to mention, one brick in this building can be the composer to manage dependencies:
well or rather i am talking about interfaces for components from which frameworks may be build. also to clarify, i am not talking about one implementation to rule them all .. i am talking about interfaces as standardized API's for common functionality.
For myself, I often find the interface/API to be part of the problem when attempting to reuse existing code, normally because I have use cases that the interface's original author has zero experience of, and therefore could not anticipate in his design.
Plus, it really isn't clear exactly what problem this will solve. A lack of interfaces isn't responsible for the projects you've named having their own HTTP clients. Technology never solves people problems, and the NIH problem definitely is a people problem.
There is a common interface for HTTP clients. It's called HttpRequest. Just happens to be not the most well-designed API (though a big step up from the pull-parameter-procedural curl everybody seems to love so much). The design of the API will always leave people unsatisfied, that's why common interfaces are not practically reachable.
That doesn't mean they are undesireable. With the recent namespacing-without-benefit craze we won't however see that. Framework developers are too occupied to throw everything into vendor namespaces, in an effort to simulate Java-esque enterpriseyness (even though namespaces were intended just to solve identifier conflicts).
Exchanging code from frameworks will mostly fail due to code intermingling. The amount of design pattern dumping does not mean the code is actually encapsulated. Instead it might make sense to dial back a bit first. Instead of asking for common interfaces, we should aim for compartmentalization and code reuse. I definitely won't be using any framework based on NIH syndrome anytime soon.
@Stu: first up .. if all the major frameworks agree on a set of interfaces, you really think that the result will be a set of interfaces that is unusable because the authors had no clue what they were doing?
second you are confusing interface with implementation. i am not talking about preventing multiple implementations. i am talking about preventing multiple implementations that implement a different interfaces only because they failed to simply follow the same interface.
again if someone then decides to do things radically different so that its impossible to fit into this common interface, so be it. then they are simply not going to work as a drop in replacement.
but for the others we will have to defined if the method is supposed to be called "send()" or "request()" etc.
@mario: I assume you are talking about the Http pecl extension. This API was essentially the work of a single developer and it was implemented in C first. I am talking about a collaboration of all/most of the major frameworks to define a set of interfaces (not only for HTTP client, but also cache, logging etc) in user land first, which can later be moved to core.
Furthermore again we are not talking about creating a "framework interface" (whatever that is) but obviously we are talking about component interfaces, aka interfaces for specific logical units of functionality like logging, caching etc.