Re: [REVIEW] PSR-16 Simple Cache

2016-11-16 Thread Larry Garfield
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

2016-11-16 Thread Cees-Jan Kiewiet
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

2016-11-16 Thread Stefano Torresi
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

2016-11-16 Thread Jeroen De Dauw
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

2016-11-16 Thread Jordi Boggiano
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

2016-11-16 Thread Andrew Carter
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

2016-11-16 Thread 'Alexander Makarov' via PHP Framework Interoperability Group
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

2016-11-16 Thread 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:

Re: [PSR-11] Characters allowed in service IDs

2016-11-16 Thread GeeH
After discussion with Larry last night I suggested an edit that states that all containers should support a valid PHP string in UTF-8 format. I made that suggestion on the pull request. G On Tuesday, 15 November 2016 05:42:42 UTC-5, Alessandro Pellizzari wrote: > > On 14/11/2016 17:50, David