-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
v2 Proposal #661
Labels
Comments
I've been doing some investigative work on what this might look like and have pushed up a potential v2 branch I'd like feedback on. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Problem
The current design of the API in redigo is making it difficult to maintain and with development of new patterns in golang it's time to consider a new major version to address these challenges as it's not possible to address these issues in a backward compatible way.
The Solution
There are a number of key changes that would help enable easier maintenance of redigo, detailed below.
Concrete Return Types
The biggest change is likely to be the removal of Conn interface, which makes it impossible to add new features without consumers using type checks for additional interfaces. Changing to concrete type returns, which is widely recommended, would eliminate this problem, allowing new features to be introduced easily. The thinking is that dial methods would return a concrete Conn type and the Pool get methods a PoolConn type.
Functional Options
Having all values on Pool type public means that it's impossible to change its internal design to incorporate enhancements. It also introduces risk as the consumer may believe it's ok to alter these once constructed which is not the case. Changing to use functional options would address this issue, improving efficiency and extensibility.
The text was updated successfully, but these errors were encountered: