Good enough answer for me, thanks Rasmus. 2016-12-30 14:48 GMT+01:00 Rasmus Schultz <ras...@mindplay.dk>:
> hasMultiple() would be dealing with several results, so is the result an > AND or OR of the individual results? > > I think, if you had something like this, it would need to be two methods: > hasAll() for the AND operation and hasAny() for the OR. > > Either way, I think that checking for the presence of multiple values is > very easy, is not something that is optimized by most back-ends (if any?) > and not an extremely common use-case - so maybe burdening every > implementation with this is a bit unnecessary? > > One other minor issue I've been wondering about is regarding getMultiple() > ... I think that the $default argument, and returning cache-keys that do > not exist may not be the most useful approach. > > In how many cases will you be fetching multiple different values and can > meaningfully replace missing *all* of them with the same default? > > I think that, in the majority of use-cases, if $default is used with > getMultiple() at all, it will be used as a work-around used to identify > missing values, rather than to set an actual default - I don't imagine a > single default will be very useful for multiple values? > > So I would have preferred a signature like getMultiple($keys) and a > return-value with missing key for missing values, so you could isset() to > check for existence. > > This would also be consistent at least with Memcached and any SQL-based > back-end. (probably the two most common/popular types of back-end?) > > On Friday, December 30, 2016 at 11:19:11 AM UTC+1, FGM wrote: >> >> 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 <ras...@mindplay.dk> >>> 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/Drive >>> r/BlackHole.php >>> >> >>> >> Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogge >>> r.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/1cf169c6674764 >>> 0c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md >>> >>> >>> >>> >>> >>> https://github.com/php-fig/fig-standards/blob/1cf169c6674764 >>> 0c6bc7fb5097d84fbafcd00a0c/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 php-fig+u...@googlegroups.com. >>> >> To post to this group, send email to php...@googlegroups.com. >>> >> 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 php-fig+u...@googlegroups.com. >>> > To post to this group, send email to php...@googlegroups.com. >>> > 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 >>> mweiero...@gmail.com >>> 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 php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/7289d19d-5f4a-47a1-bd0b-437326bc2de5%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/7289d19d-5f4a-47a1-bd0b-437326bc2de5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANqRZ1OVRaQrpb9B-nAvxDU%2BexRmBp6H4ADOh_pSoJvuLmAeXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
