Is there any reason why the interface has get/getMultiple set/setMultiple delete/deleteMultiple but only has without hasMultiple ? For the described purpose of cache warming it would make at least as much sense as for the get/set/delete operations, and I could not find a thread discussing this.
Le mardi 6 décembre 2016 20:32:52 UTC+1, Matthew Weier O'Phinney a écrit : > > On Tue, Dec 6, 2016 at 8:39 AM, Rasmus Schultz <[email protected] > <javascript:>> wrote: > > Personally, I don't use a null-cache, ever. > > > > The problem with a null-cache, is that it's not actually a cache - it > > satisfies the interface, but doesn't behave like a cache, so it's not > even > > useful for testing. > > > > I wrote this for testing where I have PSR-16 dependencies: > > > > https://github.com/kodus/mock-cache > > > > I've never had a use-case, test or otherwise, where a null-cache > actually > > satisfied the requirement. I would never add caching to something that > > doesn't require caching, and if it requires caching, a null-cache isn't > even > > a meaningful default. I honestly don't understand they're for, but maybe > > that's just me ;-) > > It's a matter of architecture. In many systems I've used and studied, > classes may require a cache to the constructor. However, in > development mode, you may want to ensure the cache is never hit — > perhaps you do not have access to the appropriate cache server, or do > not want to worry about trampling the work other developers are doing, > etc. Alternately, you may want to ensure the business logic _must_ be > hit, instead of the cached results, so that you can trace code > execution. As such, having the ability to have a null cache injected > instead of a version backed by a data store can be quite useful. > > > On Monday, December 5, 2016 at 7:02:42 PM UTC+1, Larry Garfield wrote: > >> > >> We've decided since PSR-3 that such "stock implementations" do not > belong > >> in the spec, but can live in -util libraries. A NullCache > implementation of > >> PSR-6 / PSR-16 would be very welcome for cache-util. > >> > >> On 12/05/2016 11:47 AM, Alexander Ustimenko wrote: > >> > >> Another issue that we have now in current cache and cache-util is > complete > >> missing of null-object. > >> > >> In Psr/Log we have NullLogger, why we can't have NullCache? > >> > >> There are situations, when we dont' know 100%, that there or here we > need > >> cache. Or we know, that we need cache there, but for some time we can > live > >> without it. > >> > >> Cache could be an optional dependency. It's a bitter thought, but it's > a > >> truth. So I suggest to add to Psr/Simple cache default NullCache as > just > >> /dev/null or BlackWhole implementation. > >> > >> Examples: > >> > >> https://github.com/symfony/cache/blob/master/Adapter/NullAdapter.php > >> > >> > https://github.com/tedious/Stash/blob/master/src/Stash/Driver/BlackHole.php > >> > >> Same as > https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.php > >> > >> > >> Use case > >> > >> Cache as an optional injectable dependency. When class user not > provides > >> it -- we take ready NullCache and use it. > >> > >> > >> среда, 16 ноября 2016 г., 21:22:20 UTC+7 пользователь Jordi Boggiano > >> написал: > >>> > >>> Heya, > >>> > >>> We believe PSR-16, Simple Cache, is now ready for final review. As > >>> coordinator, I hereby open the mandatory review period prior to a > formal > >>> acceptance vote; voting will begin no earlier than December 1st, 2016. > >>> > >>> Here are links to the most current version and its meta document: > >>> > >>> > >>> > https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md > > >>> > >>> > >>> > https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md > > >>> > >>> > >>> The package containing the interfaces is there: > >>> > >>> https://github.com/php-fig/simplecache > >>> > >>> > >>> The latest important changes to the interfaces can be found at: > >>> > >>> https://github.com/php-fig/simplecache/releases/tag/0.2.0 > >>> > >>> > >>> And FWIW, Scrapbook already provides a PSR-16 implementation in its > >>> upcoming release: > >>> > >>> > https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php > > >>> > >>> > >>> Thanks for your time reviewing! > >>> > >>> Cheers > >>> > >>> -- > >>> Jordi Boggiano > >>> @seldaek - http://seld.be > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "PHP Framework Interoperability Group" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> To post to this group, send email to [email protected]. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/php-fig/b67406ac-5227-456d-a7c3-f65523bf527d%40googlegroups.com. > > > >> For more options, visit https://groups.google.com/d/optout. > >> > >> > > -- > > You received this message because you are subscribed to the Google > Groups > > "PHP Framework Interoperability Group" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/php-fig/ddb02530-5460-4d90-95fa-53a7afc286f6%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Matthew Weier O'Phinney > [email protected] <javascript:> > https://mwop.net/ > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1adecc0e-c9de-4e40-b964-b5c8f125741b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
