Cheers for the feedback everyone. I will sit down with Jordi as soon as we're both available (tonight?), to go through everything. Speak soon.
On 27 Nov 2016 14:28, "Jordi Boggiano" <j.boggi...@seld.be> wrote: > > I'll try to address all formatting/wording stuff in a unified PR later, thanks. > > > On 26/11/2016 15:38, Larry Garfield wrote: >> >> * getMultiple() accepts array|Traversble, but returns an array. I would >> have expected the other way around; accept an array of short strings, >> return a traversable of "stuff". > > > See my reply to Nicolas Grekas about this, I'd be curious to hear your thoughts there, to keep it in the same thread. > > >> * For increment/decrement, returning "value or false" is an >> anti-pattern. It's a PHP language anti-pattern, but still an >> anti-pattern. Don't do that. If something breaks, throw an exception >> because the data is now invalid anyway. > > > I'd tend to agree there, as I just replied to Nicolas as well. > > >> * And the only major point: I do not think the CounterInterface belongs >> here. There's plenty of use cases for an atomic counter that are not >> part of a cache; remember a cache could get wiped at any time and the >> application must continue to function. Sometimes wiping a counter is >> OK, other times it's totally not. That a cache is used for that is an >> implementation detail. >> >> I would instead recommend splitting CounterInterface off to its own >> (small) PSR. I have no problem with small PSRs if they cover their >> target case adequately. Someone could certainly then implement both >> CounterInterface and SimpleCache\CacheInterface (or CounterInterface and >> CacheItemPoolInterface if they were so inclined) and lose nothing; or >> they could implement it on a persistent backend of some sort. > > > Yup.. I think this might be a good thing indeed. Curious to hear from Paul on this one but I'd tend to +1. > > > 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+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/36fad92d-e512-8980-9d82-9c43faa1c4eb%40seld.be . > > 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/CAKxcST8tvRxs_xGtBdiT3W_%2B3W6y5abNuctReRbDo%3DG1xatjBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
