Re: [REVIEW] PSR-16 Simple Cache

You can use `$default` in conjunction with the Null Object pattern . Whereby you usually don't want to cache *Null Objects*. For example for message board users: class UnknownUser implements User {…} // Null Object Class, providing proper

Re: [REVIEW] PSR-16 Simple Cache

It's a default value in case of a miss - it's there mainly to support an edge-case where someone is caching NULL values, and might need to pass a different default value, so they can tell the difference between a cached NULL-value and an actual miss. So in your case: $default = new

Re: [REVIEW] PSR-16 Simple Cache

I know I'm late to the party, but what's the use-case for passing a default value to the get method? If we're using a cache isn't generating/getting the value expensive? It seems to encourage something boneheaded like: $default = someExpensiveOperation(); $myValue = $myCache->get('foo',

Re: [REVIEW] PSR-16 Simple Cache

Good enough answer for me, thanks Rasmus. 2016-12-30 14:48 GMT+01:00 Rasmus Schultz : > 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

Re: [REVIEW] PSR-16 Simple Cache

On Tue, Dec 6, 2016 at 8:39 AM, Rasmus Schultz 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. > >

Re: [REVIEW] PSR-16 Simple Cache

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:

Re: [REVIEW] PSR-16 Simple Cache

I think you misunderstand. PSR-6 *does* meet some developer needs. PSR-16 is to optimize for a narrower-but-common use case. They complement each other. That's fine. Neither PSR-6 nor PSR-16 (nor PSR-7 for that matter) have implementations included in the spec or in the Packagist package.

Re: [REVIEW] PSR-16 Simple Cache

Larry, this approach is overcomplicated. NullObject of any interface can be implemented in single simple way. My PRs in OverComplexCache are still open and I dont' believe it would be merged. So let complex things will be in complex PSRs and simple ones in simple. As I understand current

Re: [REVIEW] PSR-16 Simple Cache

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

Re: [REVIEW] PSR-16 Simple Cache

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

Re: [REVIEW] PSR-16 Simple Cache

> Different CacheInterface instances MAY be backed by the same datastore, *but MUST be logically independent.* The second clause seems to be needlessly restrictive and appears to be incompatible with decorators. What is the purpose of this clause? On Wed, Nov 30, 2016 at 4:10 PM Larry Garfield

Re: [REVIEW] PSR-16 Simple Cache

On 30/11/2016 03:24, Adrien Crivelli wrote: yes a bridge has been done (https://github.com/php-fig/simplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18 ). That commit doesn't mention

Re: [REVIEW] PSR-16 Simple Cache

ok, will try to put in a PR for that tomorrow :-) On Tue, Nov 29, 2016 at 2:21 PM, Jordi Boggiano wrote: > Yes PSR-16 is meant to live alongside PSR-6, so it has to be reasonably > compatible and yes a bridge has been done (https://github.com/php-fig/si >

Re: [REVIEW] PSR-16 Simple Cache

> This is an application concern IMO, much like the management of multiple cache pools, etc. Yeah, for some types of cache-servers, flushing expired entries on-demand may not even be a thing - so this is likely outside the scope of what should be interoperable, as this kind of functionality is

Re: [REVIEW] PSR-16 Simple Cache

On Sunday, November 27, 2016 at 9:07:26 AM UTC-7, Nicolas Grekas wrote: > > > >> couldn't all these new interfaces move in the Psr\Cache namespace (thus >>> releasing them as psr/cache 1.1 on packagist?) >>> >> >> That's an interesting idea, but also kinda confusing for users because >>

Re: [REVIEW] PSR-16 Simple Cache

On 28/11/2016 09:51, Rasmus Schultz wrote: What about garbage collection? I know that some cache-servers may take care of this automatically, but for something like a file-based cache, it needs to get triggered. Is it just left up to each implementation to take care of this in whatever way

Re: [REVIEW] PSR-16 Simple Cache

We're already very committed to PSR-16 at work, so I should be able to squeeze that in - will see about getting that done in the morning :-) On Nov 27, 2016 9:56 PM, "Jordi Boggiano" wrote: > On 27/11/2016 19:45, Rasmus Schultz wrote: > >> PSR-6 used the "pool" concept

Re: [REVIEW] PSR-16 Simple Cache

On 27/11/2016 19:45, Rasmus Schultz 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

Re: [REVIEW] PSR-16 Simple Cache

> 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

Re: [REVIEW] PSR-16 Simple Cache

Notes in no particular order, most of them fairly minor/easy to fix: * Typo in the Expiration definition. " This it calculated" should be "This is calculated". It looks like that is a typo in PSR-6, too, which we ought to fix. :-) * " If a negative or zero TTL is provided, the item MUST be

Re: [REVIEW] PSR-16 Simple Cache

Hi all, as posted yesterday, I gave PSR-16 a try in Symfony Cache ( https://github.com/symfony/symfony/pull/20636). This resulted is a number of comments that I summarized in a PR on the FIG's github repo: https://github.com/php-fig/fig-standards/pull/846 Here are the collected issues/questions:

Re: [REVIEW] PSR-16 Simple Cache

On CacheInterface: > >- doesn't say what happens when $key is invalid. I guess the same >exception as PSR-6. Should be written? > > I missed adding one note here: the fact that getMultiple returns *all* keys, even cache misses, makes it impossible to (efficiently) implement a PSR-16 to

Re: [REVIEW] PSR-16 Simple Cache

One, and one last minor thing... regarding the DateInterval overload for $ttl in set() ... well ... why? Everyone is going to have to write ugly code to convert these into seconds. Ironically, the answer is first thing that auto-completes on google as soon as you type in "dateinterval",

Re: [REVIEW] PSR-16 Simple Cache

On 11/23/2016 10:57 PM, Jordi Boggiano wrote: I understand where "MUST treat an item as expired once its Expiration Time is reached" comes from, and I would agree, but for a cache it makes little sense to be so strict and adamant about it. An entry that has a TTL of 30 seconds is probably

Re: [REVIEW] PSR-16 Simple Cache

Hi Jordi (et al.), nice job! Tbh I was a bit surprised as I haven't seen any discussion about it at all after the entrance vote and I wasn't aware of it being worked on anywhere outside this ML. My fault, as I've probably missed that communication and didn't check or ask around. That said,

Re: [REVIEW] PSR-16 Simple Cache

Hey, Just wanted to say thanks everyone for the compliments and for the constructive feedback. If there's any more clarifications in the spec that you feel are *not* tight enough please continue to raise here or make a PR so we can review it. Many thanks, Paul On Fri, Nov 18, 2016 at 4:21 PM,

Re: [REVIEW] PSR-16 Simple Cache

Hi, PSR-6 makes it very clear that the expiration date/interval is really a maximum and that implementations are free to make the actual item removal happen anytime before. Actually, memcached kind of proved that *for the cache use case*, it can be verify effective to let the backend clean items

Re: [REVIEW] PSR-16 Simple Cache

I will try to add it to the meta document or maybe add more text to the spec regarding this default expiration. I think that's the best way to make people aware of it. That said, the symfony cache I mentioned for example, is a PSR-6 implementation, and will most likely implement PSR-16, while

Re: [REVIEW] PSR-16 Simple Cache

Not sure I fully understand that - as a user I can't rely on common sense implementations doing it right. If it's not part of the standard, I can't guarantee it as a feature and I can't use it. My only course of action for using that feature would be tightly coupling to a cache library that

Re: [REVIEW] PSR-16 Simple Cache

We had a quick chat off list and I believe Cees-Jan agrees with me that this is not really feasible as is. Having promise responses without a promise spec is not doable, and having optional promise responses means the interface can not be relied upon at all in libraries as it may return

Re: [REVIEW] PSR-16 Simple Cache

Thanks for the clarifications Larry. On 16/11/2016 23:13, Larry Garfield wrote: The reasoning here for PSR-6 was that a broken cache should not result in a broken program. If your cache is b0rked, then everything becomes a cache miss but the app continues to run, just slowly. (Maybe

Re: [REVIEW] PSR-16 Simple Cache

The reasoning here for PSR-6 was that a broken cache should not result in a broken program. If your cache is b0rked, then everything becomes a cache miss but the app continues to run, just slowly. (Maybe unbearably slowly, but technically still runs.) If a failed set threw an exception then

Re: [REVIEW] PSR-16 Simple Cache

This PSR looks splendid, well done. There are how ever a few concerns with regards to async PHP. I'm aware there isn't a Promise PSR yet but is it acceptable within this spec to return a promise instead of the actual value on a get? Or to resolve or reject a promise on set instead of returning

Re: [REVIEW] PSR-16 Simple Cache

Il giorno mer 16 nov 2016 alle ore 17:19 Jordi Boggiano ha scritto: > This was also carried over from PSR-6 where Pool::save() returns bool. > > I am not really sure what's best here, I expect most implementation will > throw anyway if they can't connect to the cache, and in

Re: [REVIEW] PSR-16 Simple Cache

Hey, How does this CounterInterface fit into the PSR? It seems a lot more specific than the cache interface itself. I know a lot of places where I'd have use for the later but not for the former. Cheers -- Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw Software

Re: [REVIEW] PSR-16 Simple Cache

This was also carried over from PSR-6 where Pool::save() returns bool. I am not really sure what's best here, I expect most implementation will throw anyway if they can't connect to the cache, and in other instances there is no reason a write should fail AFAIK. Any other opinions on this?

Re: [REVIEW] PSR-16 Simple Cache

Good work. One thing that always bothered me from a user perspective was not being able to put an item in the cache that doesn't expire (different from a default expiration time). Having to create times really far in advance is messy, and you never know if you're going to run into 2038 bugs

Re: [REVIEW] PSR-16 Simple Cache

Looks excellent. On Wednesday, November 16, 2016 at 5:22:20 PM UTC+3, Jordi Boggiano wrote: > > 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

[REVIEW] PSR-16 Simple Cache

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: