4 ms·
That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.
by insertnickname 10y ago
That's why we have namespaces. There's gorilla/mux and now there's donutloop/mux.
- Lewisham 10y agoThis. It's actually more idiomatic to use the same name, then you can often just sub out one library for another without any hassle.
- deleted 10y ago[deleted]
- 1_2__3 10y agoWhat? No! There's no indication at all these two libraries are compatible - why would you want two completely disparate projects to give some indication they support the same interface?
- Lewisham 10y agoBecause many of the base infrastructure libraries are compatible as long as they used interfaces (grumble grumble os.File). I would be very surprised if this doesn't implement net/http/ServeHTTP
- TheDong 10y agoIt doesn't matter what it's named though, you can always alias the import. If it was "github.com/foo/poppycock" I could just write import mux "github.com/foo/poppycock" and use it as mux. Import name similarity is a terrible argument for picking a name.
- insertnickname 10y agoThere are cases where it makes sense, like https://github.com/pkg/errors https://github.com/pkg/errors which is meant to be a drop-in replacement for the stdlib `errors` package containing a superset of its functionality.
- jerf 10y agoThen refer to the library by a name, and tell people to import $NAME/mux. You can also name the imports if people want.
- nkozyra 10y agoUnless they have the same functions, variables, structs, etc., sharing the same name really doesn't provide much in terms of hassle-free substitution.
- oelmekki 10y agoFair point, but this post title should read "donutloop/mux – A lightweight, fast HTTP request router for Go", then :)