ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back «  1  2 

Re: Why bother?

Hi Lukas,

I never said no clue ... I said zero experience of the use cases I have. That's not the same thing at all, sorry.

As to whether they'd be unusable or not ... each framework is the implementation of a philosophical approach to solving a set of problems. If my philosophy differs from all of the major frameworks (which it does), then their interfaces are unlikely to fit into my philosophy, and therefore are unlikely to be usable to me. That doesn't stop them being usable to others.

I'm definitely not confusing interface with implementation, sorry. I simply question the credibility of the idea that there's much value in multiple implementations of the same interface. Improving the interface is often a key part of producing an alternative implementation.

Can you provide 3 concrete, non-trivial, detailed examples where interfaces would make things substantially better?

Best regards,
Stu

Re: Why bother?

@stu: OK, I do not know what web sites you create, but in my 12 years as a web developer in 95% of my projects I pretty much had the same API requirements for logging and caching, which pretty much match what I have seen created in the community. Note I do not care f.e. if its called "get()" or "read()" when reading out of a cache. But I have run into situations where I would have loved to replace one implementation with another.

So apologies for assuming your situation would be similar.

As for examples: Classic example would be a tree API. For RDBMS there are various algorithms like nested set vs. materialized path vs adjacency list model. For NoSQL/Graph db's things are different again. Also for RDBMS and NoSQL/Graph's the implementation used to communicate with the storage layer will be different and many component libraries will offer their own. But the API for how to read from the tree will likely be very very similar.

I also gave another example if a trivial difference between HTTP clients with "send()" vs. "request()". For logging is it "log('info')" or "info()"? For caching is it "setTtl()" or "setLifetime()". Is it "setTtl($microseconds)" or "setTtl($time, $unit)"?

Now real world use cases of wanting to swap the implementation. Doctrine Search will likely be used by users of Zend Framework, Symfony2 and many others. Each already provides an HTTP Client with specific features. More importantly you might have extended them to fit some funky proxy/auth setup. So if Doctrine Search comes with its own client, then you will need to add the same functionality if its possible at all.

Symfony2 standard edition ships with Monolog by default. But originally it used Zend\Log and again someone that is using a lot of other Zend Framework components with Symfony2 might prefer to not use Monolog. Have a look at the Symfony2 logger interface. Note sure if its still 100% compatible with Zend\Log, but its pretty similar.

Symfony2 currently does not have a dedicated Cache component. We could start using Doctrine Common, but it actually uses the LGPL and we use MIT. So even if we decide to use Doctrine Common, we would probably want to give our users the option to easily replace it with another implementation if they are concerned about having to deal with yet another license. While the common interface might not handle every possible special feature, the bulk is really checking if something is cached, adding something to the cache and somehow configuring the lifetime.

Now I can hardly believe that your philosophy is so radically different that you will be unable to work with standardized API for logging and caching in most of your projects. At the very least I am very sure that a significant number of people in the PHP community do not have a fundamental issue with the API of Zend\Log and Monolog, but they might appreciate the "fingers crossed" logging option from Monolog which is the main reason why we switched Symfony2.

Re: Why bother?

As a developer, I would be glad to have such interfaces.

Even if the coding philosophical approach of something I develop is different and I can't reuse the "standard" interface as it is. And need to rethink of another.

When writing such implementation of my own, I'm always wondering how I should name the methods from my API. Should it be save / store / set ? Or load / retrieve / get ?

If a standard interface existed, I would use the same naming convention for sure. And everyone would use the same so it would be easier.
Even if I have different mechanism and provided a different API than the standard one. Several things would still be common.

Re: Why bother?

@Savageman:
Symfony2 has coding conventions that help us in defining consistent method names. Afaik Zend's CS also covers similar conventions. While this is of course not as definitive as interfaces, this might be useful for you in the mean time.

Re: Why bother?

I think the python WSGI standard is a good example

Re: Why bother?

I for one like your idea.

I think the source post taking up the other side of the argument makes some important points, if others are misguided.

I'm an object purist, and re-usability is a big concern of mine. Idea's that are coming out like DIC's and the focus in PHP Frameworks of Seperation of Concerns just goes to show that a lot of people are thinking about interoperability.

For example, how many frameworks implement their own version of Session handling? PHP currently has it's own procedural implementation, but others are taking on this mantle too. PHP5.4 I believe introduces this as an OOP solution. Here's the thing: if PHP provides a common interface for session handling, and provides a default implementation, then all frameworks could switch to this method. You write an application to consume one interface and with DIC you can be safe in the knowledge that your code is less likely to break.

I don't see how that can be a bad thing? And I don't see how that prevents competition.

The same thing goes for:
- HTTP Request/Response
- Database Access
- Event handling

etc etc

If you don't like the interface you don't have to use it- just expect your code not to be as portable.

«  1  2