Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: should we provide a higher level interface #210

Open
qnikst opened this issue Jun 11, 2023 · 0 comments
Open

Discussion: should we provide a higher level interface #210

qnikst opened this issue Jun 11, 2023 · 0 comments

Comments

@qnikst
Copy link
Collaborator

qnikst commented Jun 11, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant