In many cases it may worth to provide a higher level interface where it's possible to use any keys, provided by the user. And those keys will be converted to ByteString internally. It happens when the user program wants to use it's own types or use Text on the surface level, in addition it would allow the library to change internal types, for example use ShortBytestrings if the performance/memory benefits will be shown.
There are few ways how to do it:
It's possible to use already exposed RedisValue and RedisResult type classes
Introduce specialised type classes like RedisKey
Then we can provide an overloaded functions e.g.:
psetex
:: (RedisCtx m f, RedisValue key, RedisValue value)
=> key -- ^ key
-> Integer -- ^ milliseconds
-> value -- ^ value
-> m (f Status)
{-# SPECIALIZE psetex :: (RedisCtx m f) => ByteString -> Integer -> ByteString -> m (f Status)
psetex key milliseconds value = sendRequest ["PSETEX", encode key, encode milliseconds, encode value]
Using specialization we will not lose performance, but type inference will not longer work (e.g. it will not be possible to use OverloadedStrings to define keys and values inline, without passing explicit type.
So the question is whether this change is needed and if we need to provide a generalised functions in the separate module?
In many cases it may worth to provide a higher level interface where it's possible to use any keys, provided by the user. And those keys will be converted to ByteString internally. It happens when the user program wants to use it's own types or use
Text
on the surface level, in addition it would allow the library to change internal types, for example useShortBytestrings
if the performance/memory benefits will be shown.There are few ways how to do it:
RedisValue
andRedisResult
type classesRedisKey
Then we can provide an overloaded functions e.g.:
Using specialization we will not lose performance, but type inference will not longer work (e.g. it will not be possible to use
OverloadedStrings
to define keys and values inline, without passing explicit type.So the question is whether this change is needed and if we need to provide a generalised functions in the separate module?