Thanks for the reply, Rasmus. In principle I think we want the same things.
However, I think the wording in the spec is wrong, especially this part:

"Different CacheInterface instances ... MUST be logically independent."

Do you agree that the above clause from the spec makes the following class
illegal? If so, should the class be illegal?

class CacheSubset implements CacheInterface
{
    /** @var CacheInterface $cache */
    private $cache;
    private $keyPrefix;

    ...

    public function set($key, $value, $ttl = null);
    {
        return $this->cache->set($this->keyPrefix . $key, $value, $ttl);
    }

    ...
}

Surely it should be valid for an application to do the following, which
appears to me to be forbidden by the spec as it stands:

$cache = new FileCache('/tmp/foo');
$configCache = new CacheSubset($cache, $keyPrefix = 'config.');
$dbSchemaCache = new CacheSubset($cache, $keyPrefix = 'db_schema.');
// somewhere else...
$cache->clear();

On Thu, Dec 1, 2016 at 12:47 PM Rasmus Schultz <ras...@mindplay.dk> wrote:

> > why are we talking about pools in a spec which deliberately doesn't
> define them? It's out of scope.
>
> I'd say it's the other way around - the PSR-16 cache-abstraction
> represents a logical collection.
>
> The definition, in my opinion, is perfect - if we don't define what it is,
> people might assume that the abstraction is a server, in which case they
> need to concern themselves with key-collisions, accidentally clearing
> another consumer's cache-entries, and so on.
>
> The goal being simplicity, the abstraction needs to be defined explicitly
> as being a logical collection, meaning you don't have to worry about
> key-collisions and such.
>
> A consumer should be able to assume that the cache instance provided to it
> is intended for it's own use.
>

This is entirely dictated by the application being configured correctly. If
the application incorrectly provides the same cache instance to two
unrelated services then things will still break. The line in the spec which
I quoted above doesn't change this; it's still necessary for the
application to be configured correctly.


> Otherwise, we would automatically need a layer on top of PSR-16 from day
> one, to add things like key-prefixes etc. which increases complexity and
> may degrade performance.
>
> By defining the concept as being a collection, it becomes up to the
> application developer to bootstrap an application either using multiple
> cache-servers, or an implementation that supports multiple namespaces on
> one server, or in the case of a file-based cache using distinct
> root-folders, etc.
>
> That's all implementation-specific, but that only works because the
> concept of a server, for example, is outside the scope of this
> specification. Some back-ends (file-based) don't even relate with the
> concept of a server, so this is a very good thing.
>
>
>
> On Thu, Dec 1, 2016 at 12:33 PM, Josh Di Fabio <joshdifa...@gmail.com>
> wrote:
>
> > If the pools aren't logically independent, their namespaces end up 
> > colliding.
> They need to be logically distinct, even if they are on the same physical
> server.
>
> This is an application concern. It's the responsibility of the application
> to provide CacheInterface instances which are usable and correct in
> specific contexts based on the nature of the application. Also, why are
> we talking about pools in a spec which deliberately doesn't define them?
> It's out of scope.
>
> Currently, the spec appears to state that having multiple cache objects in
> memory which might overlap logically is invalid. Surely this is an
> application concern, and out of scope for this spec?
>
> > I'm not clear how that is an issue for decorators.
>
> In the following example of a trivial decorator, we have two instances of
> CacheInterface which are not logically independent. Is this invalid?
>
> class LoggingCache implements CacheInterface
> {
>     private $cache;
>     private $logger;
>
>     ...
>
>     public function set($key, $value, $ttl = null);
>     {
>         $this->logger->debug("$key was saved to the cache");
>         return $this->cache->set($key, $value, $ttl);
>     }
>
>     ...
> }
>
> How about a cache object which represents a subset of another cache object?
>
> class CacheSubset implements CacheInterface
> {
>     private $cache;
>     private $keyPrefix;
>
>     ...
>
>     public function set($key, $value, $ttl = null);
>     {
>         return $this->cache->set($this->keyPrefix . $key, $value, $ttl);
>     }
>
>     ...
> }
>
> Do you consider these examples invalid according to the wording in the
> spec?
>
> This spec should enable clients to easily work with different cache
> implementations; I don't understand why the spec needs to start interfering
> with application concerns.
>
> Does anyone other than Larry have any views on this?
>
> On Thu, Dec 1, 2016 at 10:54 AM Larry Garfield <la...@garfieldtech.com>
> wrote:
>
> On Thu, Dec 1, 2016, at 03:24 AM, Josh Di Fabio wrote:
> > > 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?
>
> If the pools aren't logically independent, their namespaces end up
> colliding. They need to be logically distinct, even if they are on the
> same physical server. I'm not clear how that is an issue for decorators.
>
> --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/1480589693.3635659.804857481.18B5A0BA%40webmail.messagingengine.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/CAKiSzdBay56qvL8W%3DSCOgyW9uUR9WXBKn-4T7TpnzjknJbYH4A%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAKiSzdBay56qvL8W%3DSCOgyW9uUR9WXBKn-4T7TpnzjknJbYH4A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
> 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_jqu%3DKFj9e2zk-g0TNT_9n1AWPrFNTtB2fF%3DdswjqOOPQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CADqTB_jqu%3DKFj9e2zk-g0TNT_9n1AWPrFNTtB2fF%3DdswjqOOPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAKiSzdBb9q4XgBmfK25OgvbpfXOewEzJOYhvYxhgUQ1c-k07kA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to