PSR-6 getExpiration

[Aaron Scherer]

I saw this was removed. What was the thinking behind removing `getExpiration` from the CacheItemInterface? Without this, the cache pool cannot save an item that needs an expiration date, without breaching the interface, from what I can see. 

[Andrew Carter]

https://3v4l.org/2TgJn

It's messy but it still can without adding extra publc methods.

There are other ways but the ones I could think of would cause a memory leak (pool would be remembering the communication method after the item had fallen out of scope).

[Larry Garfield]

I believe we spotted that early in the Review period.  The conclusion was that if a pool and item need that to communicate, they can have it.  But getExpiration() doesn't need to be part of the interface itself, and thus exposed to calling libraries.  There's nothing preventing a particular concrete implementation from having it, though.

--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+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/f4def991-0728-4c3b-a2a9-e7a25f2b2811%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[will.g...@couchbase.com]

There's not an issue here. PSR-6 is about defining a public interface. The Pool *owns* the Item therefore can communicate with it however it wishes. Items are **not** interchangeable between pools therefore they do not need to communicate using the public interface. 

On Monday, December 7, 2015 at 11:23:55 AM UTC, Aaron Scherer wrote:

[Tobias Nyholm]

Why shouldn't the cache item be interchangeable between different pools? Is there any reasons for that or is it just an effect of the (potentially) missing function?

[Andrew Carter]

This is true, but it's still a valid concern.

Implementations will want to keep public methods to a minimum (you have to provide BC support for every public method) so you shouldn't have to add public methods on top of the interface to get it working.

Likewise, in pretty much every fix for this that I can think of (which doesn't use a new public method), there is a memory leak that arises if the item is dereferenced.

Even in the example that I gave, if you had a long running process with a cache pool, creating new items and then dereferencing them, the cache pool would remember their 'ttls' and the process memory would climb unless you dereferenced the cache pool and started again.

[Larry Garfield]

On 12/07/2015 10:17 AM, Tobias Nyholm wrote:
> Why shouldn't the cache item be interchangeable between different pools? Is there any reasons for that or is it just an effect of the (potentially) missing function?

That's a deliberate part of the design. All interaction is through the
pool. if new CacheItem*() ever appears outside of the pool, You're
Doing It Wrong(tm).

For example, the item may or may not be doing some sort of lazy-loading.
In that case, it needs a reference back to the pool or underlying
datastore, which presumably is passed to the constructor. That cannot
happen if it's instantiated outside of the pool. You also do not know
(or by design care) if it's lazy loading or not. That distinction will
couple the item and pool together.

Similarly, if you have an extension for cache tags or such both the item
and pool will need to support that. If only one does, the resulting
behavior is undefined and probably results in impossible logic paths,
data loss, or cache corruption, none of which are good things.

--Larry Garfield

[Andrew Carter]

To clarify, I think that this specification forces implementations to add a public method beyind that of the specification if they are going to function.

This is a serious issue with the specification - implementations should be required to add public methods to satisfy the specification.

The other issue with the InvalidArgumentException (which is an interface and not an exception that is guaranteed to extend the root \InvalidArgumentException class) is also serious.

I really don't think that this standard is ready at all.

[Larry Garfield]

On 12/07/2015 10:21 AM, Andrew Carter wrote:
> This is true, but it's still a valid concern.
>
> Implementations will want to keep public methods to a minimum (you
> have to provide BC support for every public method) so you shouldn't
> have to add public methods on top of the interface to get it working.

Not true. Just because a method has a public keyword does *not* mean
it's part of an officially supported API.

Even if a particular implementation wanted to do so, its addition of
getExpiration() does not mean that a calling library should rely on it.
It should only rely on the interface.

If an object (generally speaking) implements 4 interfaces, and you type
hint on only one of them, then all you care about is that one. The other
3, whatever they are, are not your problem.

--Larry Garfield

[Andrew Carter]

"Not true. Just because a method has a public keyword does *not* mean it's part of an officially supported API. "

Strongly disagree. Any class implementing a public method cannot touch its signature if it wants to maintain backwards compatability.

[Anthony Ferrara]

All,

A good point was just brought up on Reddit that I think deserves
further thought:
https://www.reddit.com/r/PHP/comments/3vu9dy/psr6_is_about_to_pass_and_still_has_serious/cxrtwon

Currently CacheItemInterface has no method to receive the expiration
time that was set.

But considering that the item is passed to the pool to be saved, there
is no interface defined method for the pool to extract the expiration
from the item.

Which means that implementations cannot share items. It also means
that pools must access non-interface methods from the item. But since
the interface can't be extended, it means that there is no type safety
by design inside of Pool::save()

This means that you can't specialize CacheItem for your uses, since
it's implementation specific. This defeats the purpose of specifying
interfaces since you can't implement them yourself, you are forced
into using the one provided to you by your caching library.

This may seem trivial given the documentation "Calling Libraries MUST
NOT instantiate Item objects themselves...", but it also prevents
decorating the implementation to add additional information. In fact,
these decorating classes will fail in odd ways since the interface is
typed in the save method, not the actual one that's required.

Now, given that you specify "Calling Libraries SHOULD NOT assume that
an Item created by one Implementing Library is compatible with a Pool
from another Implementing Library." this may seem moot. However, it
also means we can't do anything via object composition between them.
So I can't use composition at all, since there are non-defined methods
required for implementations to work.

This means that if I wanted to build a multiple-tier caching system
and use patters like bridges or decorators to implement it, I
literally cannot. I'm forced to wrap all entire backends inside my own
caching system rather than just implement the piece I need.

These simple problems basically destroy all composability of the
entire specification. I can't even reliably decorate a pool to
implement the functionality I want, because I can't get the
information from the items it generates.

As far as the timing of this message, these issues have been brought
up for years. Literally. Heck, even Larry said "We've covered this
time and time again". My stance is that these things keep coming up
because they are signs that there are serious problems with the
proposal. Take that for what it means.

Anthony

> --
> 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/23d64408-6adc-4452-b565-b7784551b1ab%40googlegroups.com.

[Aaron Scherer]

Yeah, sorry, I couldn't really explain it properly when I opened this thread. I was finally able to with that post.

—
Aaron Scherer
http://bldr.io/

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/Qr4OxCf7J5Y/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAAyV7nFA1-S12ogGzTk0-_NcxBw2b%2BmRp8k_wjsWVMWSpmX_qQ%40mail.gmail.com.

[will.g...@couchbase.com]

This means that you can't specialize CacheItem for your uses, since 
it's implementation specific. This defeats the purpose of specifying 
interfaces since you can't implement them yourself, you are forced 
into using the one provided to you by your caching library. 

The purpose of the interface is so you know how to interact with the CacheItem you're given, not so you can create your own.

[ɹǝɹǝɥɔs uoɹɐɐ]

I’m not talking about creating a CacheItemInterface

A. Scherer

--
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/Qr4OxCf7J5Y/unsubscribe.
To unsubscribe from this group and all its topics, 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/359adc39-e721-478a-b620-6119917133d5%40googlegroups.com.