Re: [REVIEW] PSR-16 Simple Cache

[Michael Mayer]

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 avatar etc.

$unknownUser = new UnknownUser(); // N.B. $unknownUser is created only 
once, but can be reused multiple times 

// somewhere:
$user = $userCache->get('name of deleted user', $unknownUser);
$view->render('comment.html', ['user' => $user, …]);

This may make your code less complex 
, thus easier to read 
and understand – you do not need `if ($user === null) {…}` after each 
`->get()`.


Am Mittwoch, 15. März 2017 15:22:09 UTC+1 schrieb Brad Kent:
>
> 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', $default);
>
> I could understand passing a callable that would set the value for a cache 
> miss...
>

-- 
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/203c8680-35eb-487c-8af1-b1baf6115880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

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 stdClass(); // unique object representing a cache-miss

$myValue = $myCache->get('foo', $default); // might return a cached NULL

if ($myValue === $default) { // definitely a cache-miss
$myValue = someExpensiveOperation(); // might return NULL

$myCache->set('foo', $myValue); // might cache a NULL
}

At least that's my understanding.


On Wed, Mar 15, 2017 at 3:22 PM, Brad Kent  wrote:

> 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', $default);
>
> I could understand passing a callable that would set the value for a cache
> miss...
>
> --
> 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/
> topic/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/
> msgid/php-fig/c5c2a162-2b04-4a70-a5d4-966099831940%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+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_iKdOe8RGtFNiEgmn3DYtopLkGAgSY%3DLfj9YCJVxfku7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Brad Kent]

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', $default);

I could understand passing a callable that would set the value for a cache 
miss...

-- 
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/c5c2a162-2b04-4a70-a5d4-966099831940%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[FGM at GMail]

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 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 
>>> 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 г., 

Re: [REVIEW] PSR-16 Simple Cache

[Matthew Weier O'Phinney]

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.
>
> 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/Driver/BlackHole.php
>>
>> Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>>>
>>>
>>> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/ddb02530-5460-4d90-95fa-53a7afc286f6%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/

-- 
You received this message 

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

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 ;-)


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/Driver/BlackHole.php 
>
> Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>>  
>>
>>
>> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/ddb02530-5460-4d90-95fa-53a7afc286f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

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. That's 
fine.  For basic implementations for which there's no reason for 
everyone to re-implement them (eg, Null cache), or portions therein, we 
offer -util packages.  It currently doesn't include a null 
implementation of PSR-6 or PSR-16.  Adding one would not be difficult 
and (speaking as the nominal maintainer of the cache-util package) would 
be very welcome.


--Larry Garfield

On 12/05/2016 01:12 PM, Устименко Александр wrote:

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 PSR/Cache is not meet developers needs, so 
that we have SimpleCache PSR here.






__
Alexander Ustimenko
+7 (952) 918-02-20

2016-12-06 1:02 GMT+07:00 Larry Garfield >:


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/Driver/BlackHole.php



Same as
https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/0807a451-4055-2645-f77f-2bd668222566%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

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 PSR/Cache is not meet developers needs, so that we
have SimpleCache PSR here.





__
Alexander Ustimenko
+7 (952) 918-02-20

2016-12-06 1:02 GMT+07:00 Larry Garfield :

> 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/
>Driver/BlackHole.php
>
> Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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+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/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 a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/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/
> msgid/php-fig/614af58c-322c-2620-7a49-51e9eac15cb4%40garfieldtech.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+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/CANYF1s83AQpapNamiwANAg2%2BiVCP9zf4o6eo49swYnh7WJ5Fbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

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/Driver/BlackHole.php

Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/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+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/614af58c-322c-2620-7a49-51e9eac15cb4%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Alexander Ustimenko]

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/Driver/BlackHole.php

Same as https://github.com/php-fig/log/blob/master/Psr/Log/NullLogger.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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/b67406ac-5227-456d-a7c3-f65523bf527d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Josh Di Fabio]

> 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 
wrote:

> On 11/29/2016 02: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/simplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18
> ).
> > I agree it shouldn't sound like it depends on PSR-6 though. If you
> > have ideas how to clarify the wording PRs are welcome :)
> >
> > Cheers
>
> I've opened a PR to clarify both the PSR-6 relationship and the "cache
> is not a server" point, as they're related:
>
> https://github.com/php-fig/fig-standards/pull/851
>
> --Larry Garfield
>
> --
> 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/0cf7897f-1334-a7fd-21fb-5bed0e926024%40garfieldtech.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+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/CAKiSzdDLLb3kec8QnNa-q2%3DO3iS%3DVqCesnVq_Ge_Y8H9B3a_SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 why the bridge has been removed from the
source tree. Would you please let us know the reason ? Is it considered
out of scope ? Is it living in another package ?

To me it seems it could have been useful, but I may be missing something
obvious.


It's meant to live in a simple-cache-utils package and not in the "spec" 
one.


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/08dc2b61-c09e-75a0-be0a-5e2dde11f766%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

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
> mplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18). I agree it
> shouldn't sound like it depends on PSR-6 though. If you have ideas how to
> clarify the wording PRs are welcome :)
>
> Cheers
>
>
> On 29/11/2016 09:52, Rasmus Schultz wrote:
>
>> 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
>> implementation-specific.
>>
>> Oh, and here's a simple flat-file cache-implementation:
>>
>> https://github.com/kodus/file-cache
>>
>> It's complete, but will of course change with the coming interface
>> updates.
>>
>> I don't know if there are any other flat implementations of PSR-16 cache
>> out there? I don't see any on Packagist. So this might be helpful as a
>> real-world case.
>>
>> One other thing, about the documentation and meta... it all sounds like
>> PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
>> though PSR-16 *depends* upon PSR-6?
>>
>> That seems really wrong. I mean, PSR-16 is complete within it's own
>> scope, and has no dependency on PSR-6 whatsoever - it's perfectly
>> feasible to make PSR-16 libraries stand alone.
>>
>> I think it's great if the meta/doc states that it was designed with
>> PSR-6 compatibility in mind, making it possible to bridge PSR-6 to
>> PSR-16, but both the doc and meta at the moment make it sound like
>> that's it's only purpose...
>>
>> I personally view it as a simple alternative to PSR-6, not a layer that
>> I'm going to put over it. (I don't want to hide complexity - I want to
>> remove it and simplify.)
>>
>> Has a PSR-6 to PSR-16 bridge been implemented?
>>
>>
>> On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano > > wrote:
>>
>> 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 they need to?
>>
>>
>> Yes :) This is an application concern IMO, much like the management
>> of multiple cache pools, etc.
>>
>> If you read again my post from 4 years ago [1], PSRs I find are
>> largely beneficial for libraries and not for
>> frameworks/applications. Applications are in control, but libraries
>> have no control and are dropped in random contexts. It kinda bums me
>> out that many still don't seem to understand that (or just don't see
>> it that way?).
>>
>> It's unfortunate that FIG has framework in its name because it is
>> highly misleading, but down the line Framework-level
>> Interoperability means having interoperable libraries more than
>> frameworks being able to interact with each other.
>>
>> [1] https://seld.be/notes/one-logger-to-rule-them-all
>> 
>>
>> Cheers
>>
>> --
>> Jordi Boggiano
>> @seldaek - http://seld.be
>>
>> --
>> 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/topic/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/msgid/php-fig/13388408-c187-2738
>> -7940-1084f473be5b%40seld.be
>> > 8-7940-1084f473be5b%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 

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

> 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
implementation-specific.

Oh, and here's a simple flat-file cache-implementation:

https://github.com/kodus/file-cache

It's complete, but will of course change with the coming interface updates.

I don't know if there are any other flat implementations of PSR-16 cache
out there? I don't see any on Packagist. So this might be helpful as a
real-world case.

One other thing, about the documentation and meta... it all sounds like
PSR-16 was designed to be a layer on top of PSR-6? It almost sounds as
though PSR-16 *depends* upon PSR-6?

That seems really wrong. I mean, PSR-16 is complete within it's own scope,
and has no dependency on PSR-6 whatsoever - it's perfectly feasible to make
PSR-16 libraries stand alone.

I think it's great if the meta/doc states that it was designed with PSR-6
compatibility in mind, making it possible to bridge PSR-6 to PSR-16, but
both the doc and meta at the moment make it sound like that's it's only
purpose...

I personally view it as a simple alternative to PSR-6, not a layer that I'm
going to put over it. (I don't want to hide complexity - I want to remove
it and simplify.)

Has a PSR-6 to PSR-16 bridge been implemented?


On Mon, Nov 28, 2016 at 10:00 AM, Jordi Boggiano  wrote:

> 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 they need to?
>>
>
> Yes :) This is an application concern IMO, much like the management of
> multiple cache pools, etc.
>
> If you read again my post from 4 years ago [1], PSRs I find are largely
> beneficial for libraries and not for frameworks/applications. Applications
> are in control, but libraries have no control and are dropped in random
> contexts. It kinda bums me out that many still don't seem to understand
> that (or just don't see it that way?).
>
> It's unfortunate that FIG has framework in its name because it is highly
> misleading, but down the line Framework-level Interoperability means having
> interoperable libraries more than frameworks being able to interact with
> each other.
>
> [1] https://seld.be/notes/one-logger-to-rule-them-all
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/13388408-c187-2738-7940-1084f473be5b%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/CADqTB_gx8bysGMiQ5uep7jWE4XS8rCiz9%2BjhypjKWqOPJurZ5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Daniel Hunsaker]

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 
>> Psr\Cache would suddenly contain a Psr\Cache\Cache which sounds like the 
>> thing to use, but also the Pool.. So maybe best to just duplicate the 
>> InvalidArgumentException/CacheException into SimpleCache namespace.
>>
>
> May I suggest to name it Psr\Cache\SimpleCacheInterface (and release it as 
> psr/cache 1.1?)
> This would make the most sense to me.
>

This suggestion would make a lot more sense if PSR-16 was actually intended 
to *replace* PSR-6.  My understanding is that -16 is merely a simplified 
approach that can be used alongside -6, not an attempt to replace it 
outright.  Folding this PSR into `psr/cache` would have a number of side 
effects, including pulling in interfaces that aren't actually used, 
decreased clarity about which are which, increased complexity of 
documentation (gotta look at two separate PSRs to understand what's going 
on), and so on.  Not to mention the confusion that would follow a version 
bump (specifically this one, but also potentially others, if bugfixes are 
applied later), such as: "So is PSR-6 superceded?" "What bugfix caused a 
version bump?" "Oh, great, now my implementation is out of date..." and so 
forth.

This *could* be done, sure, but I believe both PSR-6 and PSR-16 are better 
served having separate repos for their interfaces, despite sharing some 
interfaces (at least conceptually).

Only feedback I have that I haven't seen already.

-- 
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/32400dfc-59ea-48aa-b59c-830279c551fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 they need to?


Yes :) This is an application concern IMO, much like the management of 
multiple cache pools, etc.


If you read again my post from 4 years ago [1], PSRs I find are largely 
beneficial for libraries and not for frameworks/applications. 
Applications are in control, but libraries have no control and are 
dropped in random contexts. It kinda bums me out that many still don't 
seem to understand that (or just don't see it that way?).


It's unfortunate that FIG has framework in its name because it is highly 
misleading, but down the line Framework-level Interoperability means 
having interoperable libraries more than frameworks being able to 
interact with each other.


[1] https://seld.be/notes/one-logger-to-rule-them-all

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/13388408-c187-2738-7940-1084f473be5b%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

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 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 :-)
>>
>
> Good to see I can skip the book you wrote in the previous email because
> I'm a bit short on time atm ;)
>
> I hear from Nicolas Grekas that the way PSR-6 does it is fine and
> generally not an impl problem so I guess I'm fine treating every "Cache" as
> a pool, I agree it does make it easier to interop and makes it possible for
> libs to use flush() without wreaking havoc.
>
> I'd be very happy if you or Larry could work on a spec PR that does this
> fine tuning of words though as I am kinda swamped..
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://seld.be
>
> --
> 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/572634c1-1c9a-f716-c801-ef5817a0fc6d%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/CADqTB_jV4C5ovgbz65W_bXw0vrErKUwr_Syo9StOHTiu2Y66iQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 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 :-)


Good to see I can skip the book you wrote in the previous email because 
I'm a bit short on time atm ;)


I hear from Nicolas Grekas that the way PSR-6 does it is fine and 
generally not an impl problem so I guess I'm fine treating every "Cache" 
as a pool, I agree it does make it easier to interop and makes it 
possible for libs to use flush() without wreaking havoc.


I'd be very happy if you or Larry could work on a spec PR that does this 
fine tuning of words though as I am kinda swamped..


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/572634c1-1c9a-f716-c801-ef5817a0fc6d%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

> 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"  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/
> topic/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/
> msgid/php-fig/f910ab9a-ed94-e66d-8f69-08b816d130e9%40garfieldtech.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+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.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

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 deleted from 
the cache if it exists, as it is expired already." - We discussed this a 
bit at phpWorld, though I don't recall the exact conclusion. I think we 
decided that this is already implicit in PSR-6; making it explicit here 
is probably unnecessary, but not harmful.


* In Cache Miss, make null a code snippet with `null`.

* The definition of Cache Hit appears to be missing.  Is that 
deliberate, or an oversight?


* Is there a reason the "Data" section was not borrowed from PSR-6?  I'm 
assuming all of the same logic applies to PSR-16, so it should either be 
duplicated like the definition section is or both should be omitted and 
refer to PSR-6 explicitly.


* Some docblock lines end in a period. Others don't. Please standardize 
on including the period universally.


* delete() should have a meaningful return, no?  Even set() has one, and 
in PSR-6 it returns a boolean.


* Ibid for clear().

* 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".


* array|Traversable should be array|\Traversable, or maybe iterable.

* On has(), "Identify if an item is in the cache" should probably be 
"Determines if an item is in the cache."


* I don't know that there's an official standard on verbage for 
docblocks, but I would encourage following the action-style. That is, 
read as though it begins with "this method..."  Eg, "This method... 
Persists a set of key/value pairs"; "This method... deletes multiple 
cache items..."; etc.  Currently the verb tenses are inconsistent.


* 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.


* 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.


--Larry Garfield

On 11/16/2016 03:22 PM, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md 



https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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



--
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/be14f4f9-5adf-b508-8907-34616b1df174%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Nicolas Grekas]

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:

On CacheInterface:
- doesn't say what happens when $key is invalid => the same exception as
PSR-6?
- the fact that `getMultiple` returns *all* keys, even cache misses, makes
it impossible to (efficiently) implement a PSR-16 to PSR-6 bridge, because
it makes it impossible to detect cache misses. When given an array,
`apcu_fetch` for example has this other behavior of returning only the
"hit", so it doesn't suffer from this. Could this be worth considering?
- accepting `Traversable` for `*Multiple` methods is not consistent with
PSR-6 which only takes arrays as arguments
- returning `array` for `getMultiple` is not consistent with PSR-6
`getItems` which returns `array|Traversable`
- some methods return `void` when they could return `bool` => this is both
inconsistent with some other methods, and with PSR-6

On CounterInterface:
- the draft doesn't say what happens when $key is invalid => the same
exception as PSR-6?
- nor does it say what happens when $step is not an integer => return
false? throw something?
- what should happen when $key already exists in the storage but is not
"incrementable/integer"? (Redis INCR fails, I didn't check apcu) => return
false? throw? erase and store $step? other?
- atomicity misses a normative MUST or SHOULD.

About exceptions:
- if the PSR is going to document when exceptions should be thrown, then it
should either define new exception classes or reuse those from PSR-6
- reusing exceptions defined in PSR-6 would look the most sensible to me
- yet, they are currently not in the same namespace. But: couldn't all
these new interfaces move in the Psr\Cache namespace (thus releasing them
as psr/cache 1.1 on packagist?)

Best regards,
Nicolas

-- 
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/CAOWwgpkWHWuXAzq-MSCPZ-c%2BGoahPax%2BRAwRse8C_SsXRmUp%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Nicolas Grekas]

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 PSR-6 bridge, because it makes it impossible to detect cache
misses.
when given an array, apcu_fetch for example has this other behavior of
returning only the "hit", so it doesn't suffer from this.
Could this be worth considering for a change?

Nicolas

-- 
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/CAOWwgpmEuKiQ_CaNPphWemAKnnZ4isURHJhwt-SDyBetMmk1%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Rasmus Schultz]

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", but copy/pasting this garbage 
everywhere, well, why?

Being able to specify the TTL as DateInterval is just a clumsy, round-about 
way to pass an integer argument, is it not?


$seconds = ($delta->s)
 + ($delta->i * 60)
 + ($delta->h * 60 * 60)
 + ($delta->d * 60 * 60 * 24)
 + ($delta->m * 60 * 60 * 24 * 30)
 + ($delta->y * 60 * 60 * 24 * 365);



On Friday, November 25, 2016 at 1:46:23 PM UTC+1, Rasmus Schultz wrote:
>
> Oh, also - a minor question about the decrement() method. Does it go into 
> negative when you hit zero, or does it return false, or what?
>
> On Wednesday, November 16, 2016 at 3:22:20 PM UTC+1, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>>  
>>
>>
>> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/4d133796-3988-4176-94dc-8ce53f034c0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Larry Garfield]

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 going to be fine at 31s too, especially if
expiration can't be expressed as a point in time.

Relaxing that would allow implementations to conform to the PSR-6
interface and adding stampede protection the same way apc(u) / squid do,
i.e. returning a slightly stale item while a single process is updating
the cache.

>
> Not a deal-breaker, but "SHOULD treat an item as expired" can be
> implemented as "always treat..." if anyone so desires, whereas the
> opposite is not possible.

I am a believer in pragmatism and given that I'd say an implementation 
that does this even if it violates the spec is totally fine as long as 
the user chooses it willingly and they know what it means then 
whatever. I don't think SHOULD or MUST will change a whole lot in 
practice there, but I also don't really have anything against changing 
it.. Anyone else got something to add?


We discussed the "grace period/stampede problem" at length for PSR-6.  
The end conclusion was that an implementation that wants to and is able 
to can make a grace period before expiration rather than after; viz, 
auto-regenerate a value the first time it's requested in the 5 min 
before it's expiration time rather than the 5 min after it's expiration 
time.  The net effect is the same.  The expiration time is a hard limit, 
by design.  "After this timestamp, DO NOT WANT!"


I believe PSR-6 should mimic that behavior for compatibility purposes, 
so would be against changing the MUST to SHOULD.





Alternatively, I'd suggest adding something like
CacheInterface::setDefaultTTL() and CacheInterface::TTL_NEVER = -1, with
support for the latter being subject to the actual storage capabilities.


I am rather against setDefaultTTL because that'd mean every lib and 
user has to constantly reset the default TTL to make sure they have 
the right one set, so you might as well just set the TTL you want.


Agreed.  Setting the configuration on a cache pool (which PSR-16 is as 
well, effectively) is out of scope for the spec.


TTL_NEVER however sounds like a good addition, I'd be curious to hear 
other people on this.


Cheers



We discussed this at phpworld.  Michael, do you have the notes of that 
conversation and what the outcome was?  My general recollection was a 
consensus around "be consistent with PSR-6 to avoid ugly and confusing 
bugs", but I don't recall the exact conclusion on TTL-never.



--Larry Garfield

--
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/1e30093f-2f33-216d-919d-5b4a8d0789e7%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Matteo Beccati]

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, below are my major gripes with it, inherited from PSR-6.

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 going to be fine at 31s too, especially if
expiration can't be expressed as a point in time.

Relaxing that would allow implementations to conform to the PSR-6
interface and adding stampede protection the same way apc(u) / squid do,
i.e. returning a slightly stale item while a single process is updating
the cache.

Not a deal-breaker, but "SHOULD treat an item as expired" can be
implemented as "always treat..." if anyone so desires, whereas the
opposite is not possible.

Other than that, I also am not very fond of null meaning either never or
some unspecified default value. A library would be forced to pick one as
there's no way to set an item to never expire if a default is available.
I personally like being able to specify a default TTL, but I would trade
that in exchange for something cleaner and clearer.

Alternatively, I'd suggest adding something like
CacheInterface::setDefaultTTL() and CacheInterface::TTL_NEVER = -1, with
support for the latter being subject to the actual storage capabilities.


Cheers


On 16/11/2016 15:22, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
> 
> 
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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
> 


-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
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/5ed473d6-0d38-6da9-4b0a-7fe1bcbe0641%40beccati.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Paul Dragoonis]

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, Nicolas Grekas 
wrote:

> 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 use LRU or similar.
> If PSR-6, or 16 now, would have added a requirement for storages to be
> able to store items that never expires, that would have immediately
> disqualified these strategies and related backends.
>
> Which means to me eveything is already fine for the cache use case.
>
> But this also means that PSR-6/16 are NOT fine for non-cache related use
> cases (e.g. session storage on PSR-6 is a BAD idea exactly because of this).
>
> Regards,
> Nicolas
>
>
> 2016-11-18 4:54 GMT-05:00 Jordi Boggiano :
>
>> 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 letting you
>> have items that don't expire if you use NULL. You just don't get that
>> guarantee at the spec level, I see that.
>>
>> Cheers
>>
>> On 17/11/2016 21:21, Andrew Carter wrote:
>>
>>> I don't agree with the decision, but I understand the trade off.
>>>
>>> What we're trading is the ability to set a default value in the cache
>>> configuration at the cost of not having an interoperable way for
>>> developers to create items which don't expire.
>>>
>>> From what I can tell, the PSR-6 API that we are both replacing and
>>> trying to maintain compatibility with (?) is the only cache that
>>> operates in this manner. Most other caches operate with a NULL or 0 TTL
>>> corresponding to an entry that doesn't have a natural expiry time: apc
>>> , memcache
>>> , redis
>>> , xcache
>>> , doctrine
>>> >> /latest/reference/caching.html#saving>,
>>>
>>> the symfony one you mentioned, etc..
>>>
>>> This is my last post on the subject, but I'd like whoever calls the vote
>>> to make sure that this decision and the existence of our discussion has
>>> been made clear to the voting members. I'm not sure if there's any
>>> requirement for the voting threads to draw attention to this - but I
>>> think that would be a good precedent to set if not.
>>>
>>> My last post on the subject as I think we understand each other, just
>>> disagree on the outcome.
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>>> On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:
>>>
>>> I see what you mean, but down the line it doesn't actually matter as
>>> it
>>> is merely a cache.
>>>
>>> You can never rely on anything you store in there being there when
>>> you
>>> want to read it again, no matter what expiration you set. The backend
>>> might be full and wiping stuff early, etc. All you can do is
>>> *request*
>>> that something be stored for a given amount of time.
>>>
>>> Given that fact I think that the null as it is now is kinda ok, it
>>> lets
>>> an application developer if they so wish configure their lib to make
>>> all
>>> cache entries expire after X hours by default, or they can say no
>>> actually keep everything forever unless otherwise specified, or if
>>> you
>>> have specific needs as a library author you can give specific
>>> expiration
>>> times. It adds a tiny bit of control for the app developer, and
>>> doesn't
>>> really remove anything from lib developers as they can anyway not
>>> rely
>>> on any guarantee from the cache.
>>>
>>> Does this make sense to you?
>>>
>>> Cheers,
>>> Jordi
>>>
>>>   On 17/11/2016 18:43, Andrew Carter wrote:
>>> > 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 did support items which don't
>>> expire,
>>> > and losing interoperability (as I have done in the past).
>>> >
>>> > On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
>>> wrote:
>>> >

Re: [REVIEW] PSR-16 Simple Cache

[Nicolas Grekas]

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 use LRU or similar.
If PSR-6, or 16 now, would have added a requirement for storages to be able
to store items that never expires, that would have immediately disqualified
these strategies and related backends.

Which means to me eveything is already fine for the cache use case.

But this also means that PSR-6/16 are NOT fine for non-cache related use
cases (e.g. session storage on PSR-6 is a BAD idea exactly because of this).

Regards,
Nicolas


2016-11-18 4:54 GMT-05:00 Jordi Boggiano :

> 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 letting you
> have items that don't expire if you use NULL. You just don't get that
> guarantee at the spec level, I see that.
>
> Cheers
>
> On 17/11/2016 21:21, Andrew Carter wrote:
>
>> I don't agree with the decision, but I understand the trade off.
>>
>> What we're trading is the ability to set a default value in the cache
>> configuration at the cost of not having an interoperable way for
>> developers to create items which don't expire.
>>
>> From what I can tell, the PSR-6 API that we are both replacing and
>> trying to maintain compatibility with (?) is the only cache that
>> operates in this manner. Most other caches operate with a NULL or 0 TTL
>> corresponding to an entry that doesn't have a natural expiry time: apc
>> , memcache
>> , redis
>> , xcache
>> , doctrine
>> > en/latest/reference/caching.html#saving>,
>>
>> the symfony one you mentioned, etc..
>>
>> This is my last post on the subject, but I'd like whoever calls the vote
>> to make sure that this decision and the existence of our discussion has
>> been made clear to the voting members. I'm not sure if there's any
>> requirement for the voting threads to draw attention to this - but I
>> think that would be a good precedent to set if not.
>>
>> My last post on the subject as I think we understand each other, just
>> disagree on the outcome.
>>
>> Cheers,
>>
>> Andrew
>>
>> On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:
>>
>> I see what you mean, but down the line it doesn't actually matter as
>> it
>> is merely a cache.
>>
>> You can never rely on anything you store in there being there when you
>> want to read it again, no matter what expiration you set. The backend
>> might be full and wiping stuff early, etc. All you can do is *request*
>> that something be stored for a given amount of time.
>>
>> Given that fact I think that the null as it is now is kinda ok, it
>> lets
>> an application developer if they so wish configure their lib to make
>> all
>> cache entries expire after X hours by default, or they can say no
>> actually keep everything forever unless otherwise specified, or if you
>> have specific needs as a library author you can give specific
>> expiration
>> times. It adds a tiny bit of control for the app developer, and
>> doesn't
>> really remove anything from lib developers as they can anyway not rely
>> on any guarantee from the cache.
>>
>> Does this make sense to you?
>>
>> Cheers,
>> Jordi
>>
>>   On 17/11/2016 18:43, Andrew Carter wrote:
>> > 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 did support items which don't
>> expire,
>> > and losing interoperability (as I have done in the past).
>> >
>> > On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
>> wrote:
>> >
>> > This was carried over from PSR-6 tbh, and my understanding is
>> that "an
>> > Implementing Library MAY use a configured default duration"
>> means you
>> > can very well treat null as "do not expire ever".
>> >
>> > If you read the symfony cache docs for example [1], it shows
>> that by
>> > default they treat it that way, and I'd expect others do that
>> too but I
>> > havent' researched in depth.
>> >
>>   

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 letting you 
have items that don't expire if you use NULL. You just don't get that 
guarantee at the spec level, I see that.


Cheers

On 17/11/2016 21:21, Andrew Carter wrote:

I don't agree with the decision, but I understand the trade off.

What we're trading is the ability to set a default value in the cache
configuration at the cost of not having an interoperable way for
developers to create items which don't expire.

From what I can tell, the PSR-6 API that we are both replacing and
trying to maintain compatibility with (?) is the only cache that
operates in this manner. Most other caches operate with a NULL or 0 TTL
corresponding to an entry that doesn't have a natural expiry time: apc
, memcache
, redis
, xcache
, doctrine
,
the symfony one you mentioned, etc..

This is my last post on the subject, but I'd like whoever calls the vote
to make sure that this decision and the existence of our discussion has
been made clear to the voting members. I'm not sure if there's any
requirement for the voting threads to draw attention to this - but I
think that would be a good precedent to set if not.

My last post on the subject as I think we understand each other, just
disagree on the outcome.

Cheers,

Andrew

On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:

I see what you mean, but down the line it doesn't actually matter as it
is merely a cache.

You can never rely on anything you store in there being there when you
want to read it again, no matter what expiration you set. The backend
might be full and wiping stuff early, etc. All you can do is *request*
that something be stored for a given amount of time.

Given that fact I think that the null as it is now is kinda ok, it lets
an application developer if they so wish configure their lib to make
all
cache entries expire after X hours by default, or they can say no
actually keep everything forever unless otherwise specified, or if you
have specific needs as a library author you can give specific
expiration
times. It adds a tiny bit of control for the app developer, and doesn't
really remove anything from lib developers as they can anyway not rely
on any guarantee from the cache.

Does this make sense to you?

Cheers,
Jordi

  On 17/11/2016 18:43, Andrew Carter wrote:
> 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 did support items which don't
expire,
> and losing interoperability (as I have done in the past).
>
> On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
wrote:
>
> This was carried over from PSR-6 tbh, and my understanding is
that "an
> Implementing Library MAY use a configured default duration"
means you
> can very well treat null as "do not expire ever".
>
> If you read the symfony cache docs for example [1], it shows
that by
> default they treat it that way, and I'd expect others do that
too but I
> havent' researched in depth.
>
> As such I am ok leaving it as is because the common-sense
> implementations will do it right, and it doesn't warrant
breaking away
> from PSR-6 IMO.
>
> Cheers
>
> [1]
>

https://symfony.com/doc/current/components/cache/cache_items.html#cache-item-expiration



>

>

>
>
> On 16/11/2016 17:03, Andrew Carter wrote:
> > 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

[Andrew Carter]

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 did support items which don't expire, and losing 
interoperability (as I have done in the past).

On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano wrote:
>
> This was carried over from PSR-6 tbh, and my understanding is that "an 
> Implementing Library MAY use a configured default duration" means you 
> can very well treat null as "do not expire ever". 
>
> If you read the symfony cache docs for example [1], it shows that by 
> default they treat it that way, and I'd expect others do that too but I 
> havent' researched in depth. 
>
> As such I am ok leaving it as is because the common-sense 
> implementations will do it right, and it doesn't warrant breaking away 
> from PSR-6 IMO. 
>
> Cheers 
>
> [1] 
>
> https://symfony.com/doc/current/components/cache/cache_items.html#cache-item-expiration
>  
>
> On 16/11/2016 17:03, Andrew Carter wrote: 
> > 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 etc. 
> > It's also quite common to have an entry that you don't want to expire, 
> > because you'll invalidate it yourself or wait for the cache to drop it 
> > when it's full. 
> > 
> > For me, saying that a NULL ttl means some default value somewhere is a 
> > waste of a feature. If I wanted a default value, my code can (and 
> > should) explicitly take care of that. I think documenting NULL to mean 
> > "This item doesn't expire. If the cache driver doesn't not support items 
> > that do not expire, the ttl will be set to the maximum possible." 
> > 
> > Cheers, 
> > 
> > Andrew 
> > 
> > On Wednesday, November 16, 2016 at 2:22:20 PM UTC, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
> > <
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md>
>  
>
> > 
> > 
> > 
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>  
> > <
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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
>  
> > <
> 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/2dadde75-0559-4a64-a77d-e13bbe1e5690%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/php-fig/2dadde75-0559-4a64-a77d-e13bbe1e5690%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> 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 

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 values or may return promises 
depending on which PSR-16 implementation you'd use.


One can still use a promise-based cache library in their app of course, 
but they'd have to use a PSR-6 or PSR-16 one to pass into libraries that 
require a cache.


Cheers

On 16/11/2016 22:59, Cees-Jan Kiewiet wrote:

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 true/false directly.

On Wed, Nov 16, 2016 at 8:04 PM, Stefano Torresi > wrote:


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 other
instances
there is no reason a write should fail AFAIK.

Any other opinions on this?


I don't see any compelling advantage in the boolean return value and
I'd prefer leaving it out, but there were a few people who argued in
favor of it during PSR-6 review.

As a side note, out of the most downloaded non-PSR-6 libraries
listed in the first pages of Packagist, Zend\Cache and
Doctrine\Cache do follow this convention, while almost every other
don't.

--
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/CAFojS1sV1YTy5A-rjqq5syGPMbVAcBn1WA-D62BDsgV0yVp3wg%40mail.gmail.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+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/CAPY1sU8tU7VrWvuSMjxMwd5qMvDfQbgmc0E_P2dowJMoHt%3D%2BDQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.



--
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/34f70364-2cdd-2d78-3e2c-d0c488bf29af%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

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 unbearably
slowly, but technically still runs.)  If a failed set threw an exception
then your cache server hiccuping would crash your whole application,
which is doubleplusungood.

I believe the same logic applies equally well to PSR-16.

--Larry Garfield

On 11/16/2016 11:19 AM, Jordi Boggiano wrote:

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?

On 16/11/2016 17:08, Andrew Carter wrote:

Sorry for the double post, what's the reasoning behind returning a
boolean if the set() operation fails? I'd naturally expect that to be an
exception (it's not the same as a cache miss, there must have been some
error).

On Wednesday, November 16, 2016 at 2:22:20 PM UTC, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/8fb9871d-2e1b-4922-bfc7-b123bec6528f%40googlegroups.com

.

For more options, visit https://groups.google.com/d/optout.








--
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/024c9c8d-2269-0611-ce7c-4c0ed7213fa0%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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 your cache server hiccuping would crash your whole application, 
which is doubleplusungood.


I believe the same logic applies equally well to PSR-16.

--Larry Garfield

On 11/16/2016 11:19 AM, Jordi Boggiano wrote:

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?

On 16/11/2016 17:08, Andrew Carter wrote:

Sorry for the double post, what's the reasoning behind returning a
boolean if the set() operation fails? I'd naturally expect that to be an
exception (it's not the same as a cache miss, there must have been some
error).

On Wednesday, November 16, 2016 at 2:22:20 PM UTC, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md



https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/8fb9871d-2e1b-4922-bfc7-b123bec6528f%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+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/878ae3be-3d79-9906-6314-f58ec207d158%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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
true/false directly.

On Wed, Nov 16, 2016 at 8:04 PM, Stefano Torresi  wrote:

>
> Il giorno mer 16 nov 2016 alle ore 17:19 Jordi Boggiano <
> j.boggi...@seld.be> 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 other instances
>> there is no reason a write should fail AFAIK.
>>
>> Any other opinions on this?
>>
>
> I don't see any compelling advantage in the boolean return value and I'd
> prefer leaving it out, but there were a few people who argued in favor of
> it during PSR-6 review.
>
> As a side note, out of the most downloaded non-PSR-6 libraries listed in
> the first pages of Packagist, Zend\Cache and Doctrine\Cache do follow this
> convention, while almost every other don't.
>
> --
> 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/CAFojS1sV1YTy5A-rjqq5syGPMbVAcBn1WA-
> D62BDsgV0yVp3wg%40mail.gmail.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+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/CAPY1sU8tU7VrWvuSMjxMwd5qMvDfQbgmc0E_P2dowJMoHt%3D%2BDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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 other instances
> there is no reason a write should fail AFAIK.
>
> Any other opinions on this?
>

I don't see any compelling advantage in the boolean return value and I'd
prefer leaving it out, but there were a few people who argued in favor of
it during PSR-6 review.

As a side note, out of the most downloaded non-PSR-6 libraries listed in
the first pages of Packagist, Zend\Cache and Doctrine\Cache do follow this
convention, while almost every other don't.

-- 
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/CAFojS1sV1YTy5A-rjqq5syGPMbVAcBn1WA-D62BDsgV0yVp3wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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 craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3

-- 
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/CAMhmagDiF1LYNbRYdkVQA9WmH3AUYE5TArJhhmVpEyU8oNcx9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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?

On 16/11/2016 17:08, Andrew Carter wrote:

Sorry for the double post, what's the reasoning behind returning a
boolean if the set() operation fails? I'd naturally expect that to be an
exception (it's not the same as a cache miss, there must have been some
error).

On Wednesday, November 16, 2016 at 2:22:20 PM UTC, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/8fb9871d-2e1b-4922-bfc7-b123bec6528f%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--
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/a847651a-5d4f-5b9a-4ea8-25db4796fa18%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[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 etc. It's 
also quite common to have an entry that you don't want to expire, because 
you'll invalidate it yourself or wait for the cache to drop it when it's 
full.

For me, saying that a NULL ttl means some default value somewhere is a 
waste of a feature. If I wanted a default value, my code can (and should) 
explicitly take care of that. I think documenting NULL to mean "This item 
doesn't expire. If the cache driver doesn't not support items that do not 
expire, the ttl will be set to the maximum possible."

Cheers,

Andrew

On Wednesday, November 16, 2016 at 2:22:20 PM UTC, 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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/2dadde75-0559-4a64-a77d-e13bbe1e5690%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

['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 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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
>
>
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/c29780ce-0ece-4bbf-9b21-2d7c9eef0d9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[REVIEW] PSR-16 Simple Cache

[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/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md

https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/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+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/c0e7d147-e0b2-406f-d750-1a52120b0b59%40seld.be.
For more options, visit https://groups.google.com/d/optout.