4 ms·
I think you may have lost track of what this thread is discussing. To be more concrete, let's say you have the following code (pseudo-Go): package main im
by jmillikin 4y ago
I think you may have lost track of what this thread is discussing.
To be more concrete, let's say you have the following code (pseudo-Go):
package main
import "example.com/http_server" // v2
import "example.com/utils" // transitively depends on http_server v1
function main() {
var srv *http_server.Server = http_server.New()
utils.ServeHttp(srv)
}
You're going to have a problem, because ServeHttp expects an HTTP server struct from the v1 API, and you're passing in a struct from the v2 API.
If you tried to write an adapter for this then (1) you'd need to somehow construct a concrete proxy of a type you don't control, and (2) there's no way to import both the v1 and v2 APIs at the same time in your code, so you don't have a way to declare a conversion function.
That's why APIs with versions declared by dependency edges are impractical.
- mseepgood 4y ago> there's no way to import both the v1 and v2 APIs at the same time in your code, so you don't have a way to declare a conversion function. In Go major versions have different import paths. You can import multiple major versions of the same library: import ( http_server_old "example.com/http_server" http_server_new "example.com/http_server/v2" )
- jmillikin 4y agoSure, but that's not what's being discussed here. In C and C++, it's idiomatic to have different major versions use the same includeable name, with the version resolution handled by the build system.
- staunton 4y ago... where "build system" means a bunch of preprocessor macros, at which point you just use the oldest version of everything available and never update anything that works.