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