Based on experience with other redis libraries, one feature that predis may find useful to supplement the transparent key prefixing is a simple convention to generate a new prefix'd client instance from an existing instance.
One possible interface would look like:
$appClient = $client->prefix('myapp:dev:');
and you could further prefix into a new client
$featureClient = $appClient->prefix('some_feature:');
A complete hack which demonstrates this is here: https://gist.github.com/4228720
interesting, I can actually see its usefulness but I feel that prefix as a method name does not really describe well its behavior since in this case prefixing is incremental and the string argument is appended to an existing prefix... or is it just me worrying too much?
EDIT: I mean, it makes sense that prefixing a prefix logically means appending a string to the old one, but the rest of the library works by replacing the prefix in both client options and Predis\Command\Processor\KeyPrefixProcessor.
Thinking about it in the meanwhile.
To keep things conceptually different, perhaps namespace would be a more appropriate method name? In truth i'm not sure what name fully captures the concept of both extending the prefix and returning a new instance. To bring clarity to the first half extendPrefix might provide some of that distinction. Making the method static might make it more obvious you will receive a new instance, although i'm not sure i prefer the syntax.
One option is to use a name other than prefix to keep the concept seperate
$appClient = $client->namespace('dev:app:');
$featureClient = $appClient->namespace('feature:');
A direct client method is convenient and short. The downside with this is that it is not obvious a new instance will be returned.
$appClient = $client->extendPrefix('dev:app:');
$featureClient = $appClient->extendPrefix('feature:');
More verbose, but perhaps makes reading the code more descriptive?
$appClient = Predis\Client::extendPrefix($client, 'dev:app:');
$featureClient = Predis\Client::extendPrefix($appClient, 'feature:');
Unfortunately I couldn't find a decent approach for this request and I'd avoid tying this to the client. In the end I prefer to close this issue and leave to developers to implement their own logic to handle such cases.
Thanks anyway @ecitecm for the time spent describing your feature request!