On Tue, Dec 6, 2016 at 8:39 AM, Rasmus Schultz <[email protected]> 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]. > 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/ddb02530-5460-4d90-95fa-53a7afc286f6%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Matthew Weier O'Phinney [email protected] 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/CAJp_myW6Bnio9mtZXK_k2z7oLZs_xVnkoJkwxqp%3DgrrSKbtU0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
