Will this package implement PSR-6 interfaces? about cache HOT 18 CLOSED

IMO, it's undemocratic.

We are software designers, not a committee. We are here to build the best solution (according to our needs), and PSR-6 is a sub-optimal interface that is actually much more complex and much less usable than doctrine/cache 1.x, as it stands.

In most cases, a simple __construct(callable $cacheFetch, callable $cachePut) is a sufficient interface for using a cache. A wrapper can gladly increase that complexity (for no reason, IMO) to provide interface implementations, if needed.

That said:

• doctrine/cache is this popular because it is simple to use
• doctrine/cache was initially developed for internal usage, and got popular due to its simplicity and OOTB integration with the ORM
• doctrine/cache 2.0 will likely keep the simple interface for external consumer, while introducing interfaces similar to the ones found in JSR-107 in order to ease development and improve performance in ORM v3
• doctrine project is a project focused on persistence-oriented problems: cache may be one of our most popular libraries, but it is not the primary focus of this organization
• there are 0 advantages in switching to PSR-6 for doctrine

We voted against PSR-6 because we think that it is a bad interface from a design perspective: author, popularity, the fact that it comes from FIG, the fact that it tries to solve problems that we don't solve don't really matter.

Using an adapter is a valid solution: use it, if you need PSR-6. Switch to something different if doctrine is un-fit. We are not trying to be popular, we're trying to build good software.

from cache.

Indeed not going to happen for now: the interface of doctrine/cache is not going to change, but you are free to implement a PSR-6 compatible adapter, if you want.

from cache.

There is already one here: https://github.com/php-cache

In both direction: doctrine->PSR-6 and PSR-6->doctrine.

from cache.

@Ocramius are you anyway interested by a PR implementing PSR-6 for doctrine/cache:2.0.0 or it's really not relevant for you ? IMO, PSR-6 allows to plan the next major version of this (fabulous) project.

from cache.

@maidmaid PSR-6 has some completely fundamental design flaws that don't make it a good candidate for implementation in any of the doctrine packages, from our point of view.

@guilhermeblanco is designing a cache package (completely independent) that will help us work on ORM v3, but we're far from getting anywhere right now, and we're not designing it for external consumption, rather than for internal ORM consumption first.

Cache 1.x is pretty much covering the 90% of use-cases (outside the ORM) anyway, so I don't see a necessity for changing its API right now. It is not perfect, but it works and it is simple (compare it with a few implementations out there).

from cache.

Some experimental work for Doctrine\Cache 2.0 is already being done at https://github.com/guilhermeblanco/cache

from cache.

I think it's too bad because that project is the reference of php cache (currently 432 dependents !) and now, current and next projects will want use an interoperable cache and doctrine cache won't be natively.

I totally understand that cache 1.x won't be redesigned but I would be fine imo that plan a interoperable PSR-6 compliant v2.

from cache.

For the time being you can use these packages as wrappers:

https://github.com/php-cache/doctrine-adapter
https://github.com/php-cache/doctrine-bridge

I am quite happy with them.

from cache.

Yes @sagikazarmark, this adapter/bridge are very useful for doctrine cache 1.x but I propose that doctrine cache v2 is PSR-6 compliant and will no longer need any wrappers.

from cache.

Well, I also agree with @Ocramius: releasing PSR-6 in the current form was a mistake. I think a major part of the FIG requested revoting on it, but it was rejected. I think we have to live with this for now, even if this means doctrine will never implement it.

But if what @Ocramius says is true, then doctrine cache will be an internal layer for doctrine, which means you should not use it.

from cache.

releasing PSR-6 in the current form was a mistake.

@sagikazarmark could you develop your idea please?

from cache.

At the time vote started there were many open questions unanswered (even about interface naming). Those questions were just ignored by saying "I disagree". I don't blame the authors for disagreeing, but I think they just wanted it out, so they were a bit lazy to address all the issues. I partly blame FIG members waking up at the last moment with their concerns (although not all of the concerns were last minute ones, but there were quite a few).

All in all: I can understand why doctrine does not want to implement it, but I guess we have to live with that.

from cache.

@sagikazarmark I am disappointed to learn that (and you are courageous to dare say)... Nevertheless, PSR-6 is running : currently there are 49 dependents including php-cache, Symfony, Stash and more to come... Is it not better to follow the community?

from cache.

I didn't say it is not better, neither there are no benefits in having it released finally.

Also, I don't think it is a bad thing to admit that PSR-6 didn't make everyone happy and I think it is the key to understand why doctrine does not want to implement it. It's not like the good guys implement it, the bad guys don't.

All I said I can understand why doctrine rejects it and the reasons belong to the big picture.

from cache.

I'll give my opinion with the same honesty that you: I can understand that doctrine doesn't agree with PSR-6 and with FIG process, but once this is released, I don't understand his refusal to implement it because this choice is detrimental to the community (obviously, we will be completely penalized because there are wrappers developped by the community and that you quoted, but it would be easier if we would not need it). IMO, it's undemocratic.

from cache.

I think it depends on the purpose of the library. If it's purpose is to work closely with doctrine and not to provide a common cache library, then I don't see an urge to implement PSR-6. Even if it became viral and everyone use it.

Also, as we heard, doctrine/cache will become more of an internal library with the upcoming release.

from cache.

You can see doctrine/cache how an series of adapter for a possible PSR-6 implementation.
In my opinion is not needed that this layer is in this library.

from cache.

@Ocramius 👍

from cache.