v2 Proposal
stevenh opened this issue · 2 comments
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.
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.