informatikr / hedis

A Redis client library for Haskell.
http://hackage.haskell.org/package/hedis
BSD 3-Clause "New" or "Revised" License
329 stars 127 forks source link

Discussion: should we provide a higher level interface #210

Open qnikst opened 1 year ago

qnikst commented 1 year ago

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:

  1. It's possible to use already exposed RedisValue and RedisResult type classes
  2. 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?