How to support multiple versions of the same interface?
I am writing a go module that implements a structure that satisfies the interface. We only want to maintain a single version of the library, but our customers use multiple versions of one of our dependencies.
The dependencies provide the interface we want to implement, as shown below.
type supercoolinterface interface { dooldcoolthing(value string) }
Our implementation is like this.
type supercoolimpl struct {} func (sc *supercoolimpl) dooldcoolthing(value string) {}
New versions of dependencies add new types in the types module.
type newtype struct { value string }
The dependency adds a method to the interface.
type supercoolinterface interface { dooldcoolthing(value string) donewcoolthing(value types.newtype) }
Now, if I implement the new method, it won't compile with the old version of the library because types.newtype
doesn't exist. However, I can't satisfy the new version of the interface if I don't implement the new version.
type SuperCoolImpl struct {} func (sc *SuperCoolImpl) DoOldCoolThing(value string) {} func (sc *SuperCoolImpl) DoNewCoolThing(value types.NewType) {}
Do we need to fork the code to support this version? In languages with preprocessors, there is a simple solution, so I'm assuming go must have a solution that I'm missing.
We plan to continue developing and supporting both versions, so it would be annoying to need to ensure consistency between two different versions. I'm hoping I can do something with reflection or something similar to the c preprocessor where I can define a preprocessor value and only implement the method if we instruct the version of the library to have the correct type.
Correct answer
I found a solution that works for my situation.
Thanks to @Burak Serdar for pointing me in the right direction.
My solution was to put the old implementation into the impl/v0 package and the new implementation into the impl/v1 package.
Clients using older versions of dependencies will use impl/v0, and clients using newer versions of dependencies will use impl/v1.
Since golang only compiles directly imported code, only packages with the correct interface version will be compiled, so both directions will be compiled successfully.
This alleviates my concerns about having to fork the entire library.
Edit: If anyone uses this solution, there is a problem if you are currently running your tests using go test ./...
. The command seems to try to build every module whether it contains tests or not.
But you can exclude the tests using go test $(go list ./... | grep -v <path_to_ignore>)</path_to_ignore>
and then you can run these against the correct version in another command test.
The above is the detailed content of How to support multiple versions of the same interface?. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

This article explains Go's package import mechanisms: named imports (e.g., import "fmt") and blank imports (e.g., import _ "fmt"). Named imports make package contents accessible, while blank imports only execute t

This article explains Beego's NewFlash() function for inter-page data transfer in web applications. It focuses on using NewFlash() to display temporary messages (success, error, warning) between controllers, leveraging the session mechanism. Limita

This article details efficient conversion of MySQL query results into Go struct slices. It emphasizes using database/sql's Scan method for optimal performance, avoiding manual parsing. Best practices for struct field mapping using db tags and robus

This article demonstrates creating mocks and stubs in Go for unit testing. It emphasizes using interfaces, provides examples of mock implementations, and discusses best practices like keeping mocks focused and using assertion libraries. The articl

This article explores Go's custom type constraints for generics. It details how interfaces define minimum type requirements for generic functions, improving type safety and code reusability. The article also discusses limitations and best practices

This article details efficient file writing in Go, comparing os.WriteFile (suitable for small files) with os.OpenFile and buffered writes (optimal for large files). It emphasizes robust error handling, using defer, and checking for specific errors.

The article discusses writing unit tests in Go, covering best practices, mocking techniques, and tools for efficient test management.

This article explores using tracing tools to analyze Go application execution flow. It discusses manual and automatic instrumentation techniques, comparing tools like Jaeger, Zipkin, and OpenTelemetry, and highlighting effective data visualization
