7 ms·
This. It's actually more idiomatic to use the same name, then you can often just sub out one library for another without any hassle.
by Lewisham 10y ago
This. 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.