[PSR-6] Decoupling CacheItem from CacheItemPool

123 views
Skip to first unread message

rindeal

unread,
Aug 23, 2015, 9:38:36 PM8/23/15
to PHP Framework Interoperability Group

As already pointed out in #389, method exists() is the only method in CacheItemInterface which requires to know which CacheItemPool the item belongs to.

When trying to figure out, why exists() exists at all, I stumbled upon this article, which explains that the reason is memory efficiency for someone who just needs to peek into the cache to see if the item exists without caring what it's value is. To avoid race conditions the caller will also likely not use any other method provided in CacheItemInterface, unless he calls getItem() again.


To sum it up, I see no reason why exists() shouldn't be moved to CacheItemPoolInterface.


Note: the above text is copypasted from #609.

Matteo Beccati

unread,
Aug 25, 2015, 3:47:15 AM8/25/15
to php...@googlegroups.com
Hi,

I agree. In fact I don't think the use cases are compelling enough to
have a separate non-atomic exists at all.

If we really want one though, it belongs to the pool.


On 24/08/2015 03:38, rindeal wrote:
> As already pointed out in #389
> <https://github.com/php-fig/fig-standards/issues/389>, method |exists()|
> is the only method in |CacheItemInterface| which requires to know which
> |CacheItemPool| the item belongs to.
>
> When trying to figure out, why |exists()| exists at all, I stumbled upon
> this article
> <http://blog.ircmaxell.com/2014/10/a-followup-to-open-letter-to-php-fig.html>,
> which explains that the reason is memory efficiency for someone who just
> needs to peek into the cache to see if the item exists without caring
> what it's value is. To avoid race conditions the caller will also likely
> not use any other method provided in |CacheItemInterface|, unless he
> calls |getItem()| again.
>
>
> To sum it up, I see no reason why |exists()| shouldn't be moved to
> |CacheItemPoolInterface|.
>
>
> Note: the above text is copypasted from #609
> <https://github.com/php-fig/fig-standards/issues/609>.
>
> --
> 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
> <mailto:php-fig+u...@googlegroups.com>.
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/e1fb8401-5320-4c48-8870-66f6cfe35372%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/e1fb8401-5320-4c48-8870-66f6cfe35372%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--
Matteo Beccati

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

Robert Hafner

unread,
Aug 25, 2015, 4:20:33 AM8/25/15
to php...@googlegroups.com
I don’t care if it exists, but agree that moving it to the pool makes sense. So remove it to move it, I’m okay with either.

We’re not in review anymore, so make a pull request and we can see where this goes.

Rob
> 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/55DC1D74.6090402%40beccati.com.

rindeal

unread,
Aug 25, 2015, 8:21:30 AM8/25/15
to PHP Framework Interoperability Group

Paul Dragoonis

unread,
Aug 25, 2015, 5:11:28 PM8/25/15
to php...@googlegroups.com
On Tue, Aug 25, 2015 at 9:20 AM, Robert Hafner <ted...@tedivm.com> wrote:
I don’t care if it exists, but agree that moving it to the pool makes sense. So remove it to move it, I’m okay with either.

We’re not in review anymore, so make a pull request and we can see where this goes.

Rob

+1 on moving it back to where it belongs ;-)
 

rindeal

unread,
Sep 8, 2015, 1:35:11 PM9/8/15
to PHP Framework Interoperability Group
As time went I made some deeper changes to the PR including a naming change (itemExists ---> hasItem) and related docs changes. Any feedback would be appreciated.
Reply all
Reply to author
Forward
0 new messages