v2 Proposal

[stevenh]

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.

[stevenh]

This would enable the elimination of dual command processing required due to interface returns in #658 if would help make implementing the #656 and #568 easier

[stevenh]

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.