Hey all, 1. CounterInterface *will* be dropped from PSR-16 and I will split it off onto a separate PSR, which can be generically used in other PSRs or implementations at will.
2. SimpleCache will throw InvalidArgumentException from the SimpleCache namespace (not from the PSR-6 Cache namespace) 3. The typehint array|Traversable will remain on all existing methods. This allows for an extensible implementation around this PSR. This also happens to align with PSR-6 which is a bonus. 4. The return value of getMultiple() *will *contain all keys passed, even if that key is not found. This also happens to align with PSR-6 which is a bonus. Many thanks, Paul On Sun, Nov 27, 2016 at 6:45 PM, Rasmus Schultz <ras...@mindplay.dk> wrote: > > PSR-6 used the "pool" concept rather than "server" specifically for this > reason; each "pool" is a separate logical namespace independent of any > other pool, and two pool objects should not interact. They could both be > backed by a file system (separate directories), or by the same SQL database > connection (separate tables), or entirely separate Redis servers, or the > same Redis server with automatic prefixing... that's all an implementation > detail. At a logical level they're independent collections. > > Yeah, this perfectly summarizes what I managed to put in way too many > words. Thanks, Larry :-) > > On Nov 27, 2016 19:33, "Larry Garfield" <la...@garfieldtech.com> wrote: > >> On 11/27/2016 06:20 PM, Rasmus Schultz wrote: >> >> > As I understand what you said, PSR-16 represents a cache server, and >> flush() would wipe everything on there. >> >> I find this answer highly problematic, because that means that there is >> *no* concept to support back-ends that can (efficiently or not) support >> multiple collections. >> >> >> *snip* >> >> A server-abstraction *precludes* implementations that support multiple >> collections - a clear() method, by definition, would clear the contents of >> the *server*. >> >> Compare this with a collection-abstraction, where a clear() method, by >> definition, clears the contents of the *collection*. >> >> The latter does *not* prevent you from having a collection that happens >> to be a server. >> >> The former *does* prevent you from having a server that supports multiple >> collections, which just isn't the reality we have. >> >> >> I largely agree with Rasmus here, although the difference is very subtle >> and likely no more than one or two words in the spec. >> >> PSR-6 used the "pool" concept rather than "server" specifically for this >> reason; each "pool" is a separate logical namespace independent of any >> other pool, and two pool objects should not interact. They could both be >> backed by a file system (separate directories), or by the same SQL database >> connection (separate tables), or entirely separate Redis servers, or the >> same Redis server with automatic prefixing... that's all an implementation >> detail. At a logical level they're independent collections. >> >> PSR-16 should follow the same assumption. In practice I don't think the >> spec need change for that, or if it does only by a word or two somewhere >> when discussing what the object represents. >> >> Disclaimer: I am largely approaching PSR-16 as a "streamlined" interface >> atop PSR-6, via a standardized bridge, as I expect that to be the typical >> use case. For that reason, most underlying semantics can and should be >> borrowed from PSR-6 directly, as we already figured those out at length and >> those aren't the parts people had issues with. :-) So my default position >> on most questions for PSR-16 is "do as PSR-6 does, unless there's a >> compelling streamlining reason to do otherwise." I think that will give >> the most usable and easiest to implement end-result. >> >> --Larry Garfield >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "PHP Framework Interoperability Group" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/php-fig/kSj_yVbkwOw/unsubscribe. >> To unsubscribe from this group and all its topics, 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/ms >> gid/php-fig/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.com >> <https://groups.google.com/d/msgid/php-fig/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.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/CADqTB_jOkXiN1UdLL-WFigPUeVhfN1xOuWUPMPQ-gXE% > 2BbiAB%3DA%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CADqTB_jOkXiN1UdLL-WFigPUeVhfN1xOuWUPMPQ-gXE%2BbiAB%3DA%40mail.gmail.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/CAKxcST-XUoHOeC%2B1-PdRqqAMdwQKZNycyJMzUk4ML%3DKcK61JSw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
