> 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 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/CAKiSzdBay56qvL8W%3DSCOgyW9uUR9WXBKn-4T7TpnzjknJbYH4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
