Matt, you probably get me wrong. I mentioned I was tired of personal preference was about all lately "tabs vs spaces" on php-fig. =)
Personally I'd think if everyone thinks PSR is the way to go for everyone to release a possible cache implementation, I'd love to help there and deprecate Doctrine\Cache. But if FIG focus only on interfaces (which is another perspective from many), then I'll work my best to have a solid, stable component that is PSR compliant on Doctrine. The only thing I feel bad is to see people reinventing the wheel on every project because A they don't like the implementation, B because of license constraints, C because they want their own namespace or D company limitations. I am a huge evangelist of OS and I think PSR should release their own code that everyone would reuse. I can't see better argument to probably have same implementation being ported to PHP itself. But for now, I think we have in FIG brililant minds that could help and their effort would also help everyone. Cheers, On Sat, Mar 23, 2013 at 7:34 PM, Matt Robinson <m...@lazycat.org> wrote: > Ouch. I'd be the first to argue that my personal preference shouldn't > decide where Symfony should go, and it's very possible (even likely) that > my opinion is wrong, but it's not stupid. :) > > I never meant to suggest that we make yet another cache implementation > completely in isolation from anything that has come before (although > scrolling down, it could easily look like that - sorry, not my intention!) > > So let me rephrase and explain myself: where Symfony uses a cache backend, > it should use the PSR Cache interface (when it's released). For > convenience, it should also come with a component that implements that > interface. That component should probably use Doctrine Cache as its own > backend (it would be silly to write one from scratch). Then you can swap in > anything that implements the PSR, just like you can replace the Symfony > HTTP cache with Varnish, and Monolog with any other PSR-3 logger. > > Changing Doctrine Cache to implement the cache PSR and then using it > directly looks to me like a trivial amount of coding, but it has wider > implications and shouldn't be done quickly: lots of projects already use > its current interface, and if you maintained BC by implementing both > interfaces developers might (horribly) use methods from both, so really > you're talking about making Doctrine Cache 3.0, not say 2.4. On the other > hand, making a Symfony cache component that wraps the current Doctrine > Cache with a PSR interface is very little work too and prevents the Symfony > release schedule being held to another 3rd party project's timescales (and > Doctrine's release schedule being pressured by Symfony). That's what I > meant by a Symfony cache component. > > Kind regards, > > -- Matt Robinson > > On 23 Mar 2013, at 19:42, "guilhermebla...@gmail.com" < > guilhermebla...@gmail.com> wrote: > > @Matt, having pattern and wildcard cannot work since most cache providers > to not expose API for this type of usage. =( > > I personally think Doctrine Cache is good enough as a start, but of course > there're updates that we could do. > If FIG would want to provide a common interface or even a common code for > everyone to use it, I'd love to give a hand implementing it. > Personally I feel extremely tired nowadays of current threads rolling out > there as people are discussing (sorry, but..( stupid personal preferences > instead of common goal. > > Cheers, > > > On Sat, Mar 23, 2013 at 3:03 PM, Matt Robinson <m...@lazycat.org> wrote: > >> I'd love to see FIG standardise a cache interface and for Symfony to have >> an exemplary implementation of it, but that doesn't necessarily mean it >> needs to be a Symfony component if something better already exists. >> >> Personally though I don't think Doctrine Cache is that something. At >> least not yet. It doesn't quite feel "Symfonic" (weird, since it's already >> part of Doctrine ORM), and since its current interface has no methods in >> common with the PSR proposal, it seems it would be more work to change it >> (and everything that uses it) than to accept one of the PRs mentioned below >> and document it. I could be dead wrong though; DC's support for patterns & >> wildcards is really neat, for example, and it's a stable and well-tested >> library as far as I can tell. >> >> On balance, I think I'd rather see a new Symfony Cache component. >> >> On 23 Mar 2013, at 17:21, Florin Patan <florinpa...@gmail.com> wrote: >> >> Hi Fabien, >> >> >> Nice to see some activity for this. >> >> I think we should get this done after FIG does their job as it would help >> the >> community but after a long time discussing this, FIG has been quiet this >> week. >> >> Maybe a fresh set of eyes from Symfony community members on the >> FIG ML here: https://groups.google.com/forum/#!topic/php-fig/UkSWS48eEgo >> >> Paul did a great job in trying to summarize and get the best out of all >> proposals for FIG and there's also the long standing proposal from Robert. >> >> As for Symfony2 strictly, if FIG adopts a PSR and then Doctrine makes >> a move to become compatible with it I don't see why we couldn't rely on >> Doctrine Cache to provide the caching layer, just like we have Monolog. >> >> Have a nice weekend. >> >> >> Best regards, >> Florin >> >> On Saturday, March 23, 2013 7:11:56 PM UTC+2, Fabien Potencier wrote: >>> >>> Hi all, >>> >>> There is probably one missing component in Symfony: a cache one. There >>> is already a ticket and 4 PRs on this topic, but I think we need to >>> discuss what we want to do before writing any code. Also because there >>> have been a lot of discussions already on the FIG group, so we also need >>> to discuss what is our position about this too. >>> >>> I'm pretty sure that we won't have time to finish anything serious >>> before 2.3, so we have time to get it right. >>> >>> For reference, here are the ticket on Symfony: >>> >>> https://github.com/symfony/symfony/issues/1513 >>> >>> And the 4 PRs: >>> >>> https://github.com/symfony/symfony/issues/3211 >>> https://github.com/symfony/symfony/issues/3225 >>> https://github.com/symfony/symfony/issues/5902 >>> https://github.com/symfony/symfony/issues/5903 >>> >>> Let's start the discussion! >>> >>> Fabien >>> >>> -- >>> Fabien Potencier >>> SensioLabs CEO - Symfony lead developer >>> sensiolabs.com | symfony.com | fabien.potencier.org >>> +33 1 40 99 80 80 >>> >> >> -- >> -- >> If you want to report a vulnerability issue on Symfony, please read the >> procedure on http://symfony.com/security >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfony-devs@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-devs+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Symfony developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to symfony-devs+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> >> -- >> -- >> If you want to report a vulnerability issue on Symfony, please read the >> procedure on http://symfony.com/security >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfony-devs@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-devs+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Symfony developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to symfony-devs+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Guilherme Blanco > MSN: guilhermebla...@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada > > -- > -- > If you want to report a vulnerability issue on Symfony, please read the > procedure on http://symfony.com/security > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Symfony developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to symfony-devs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > If you want to report a vulnerability issue on Symfony, please read the > procedure on http://symfony.com/security > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Symfony developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to symfony-devs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en --- You received this message because you are subscribed to the Google Groups "Symfony developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to symfony-devs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
