> Do you agree that the above clause from the spec makes the following class illegal?
Illegal? Heh. No :-) If it makes sense within your project to bootstrap things that way - assuming you *want* one collection's clear() method to clear all other collections, that's "your problem", so to speak. I don't know why you'd want that. Dealing with logically independent collections is much safer and simpler. I wouldn't use that. But of course you're free to do whatever you want. On Thu, Dec 1, 2016 at 3:32 PM, Josh Di Fabio <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 >> [email protected]. >> >> >> To post to this group, send email to [email protected]. >> >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 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 > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/CAKiSzdBb9q4XgBmfK25OgvbpfXOewEzJOYhvYxhgUQ1c-k07kA%40mail. > gmail.com > <https://groups.google.com/d/msgid/php-fig/CAKiSzdBb9q4XgBmfK25OgvbpfXOewEzJOYhvYxhgUQ1c-k07kA%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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_girHOO0pR8P%3DuuVoQ-UHMy8n14nqQbpdYsb6VMJSw_NQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
