3 ms·

With the subpackage, did you actually put the stuff in subfolders of the original package, or did they have two different top-level folder names? In other words

With the subpackage, did you actually put the stuff in subfolders of the original package, or did they have two different top-level folder names? In other words, was it import ( "github.com/foo/x-core" "github.com/foo/x-adapters" ) or import ( "github.com/foo/x" "github.com/foo/x/adapters" ) If the second, then do you need to do something special with regards to compilation or anything else? One thing that bugs me with the second approach is that the package names then have to be different. If the original core package is called "x", and you have an "adapters" package, would the package name be something like "x_adapters"? Just "adapters" seems a bit presumptuous (it's very generic).

grey-area 14y ago
Because packages are namespaced by user, and it's easy to rename imports, I don't worry about choosing obvious names - that's only a problem if it is popular and used by more people than me anyway :) So I'm using obvious names, with the pkg (say core) in one folder, and subpkg in the subfolder named adapters. "github.com/user/core" this has a few .go files in it to split things up into different concerns, and a subpackage with adapters (again with a few files), imported with: "github.com/user/core/adapters" and using adapters.XXX in the core code. You can also do this: import ( mypkg "github.com/user/core/adapters" ) and use mypkg.XXX to refer to the subpackage, so you're not tied to the folder names for package import names, that's just the convention, and if someone needs to rewrite the name on import, they can do so.
- lobster_johnson 14y ago
  True, although it gets annoying having to "rename" a package like this. If it's a package you use everywhere in your project, it gets old fast; canonical, author-defined names are always the best option.
  - grey-area 14y ago
    Yes, it could be a pain unless it was just imported in one or two files. In practice though I've not found collisions in package names to be an issue, simply because of the layering of packages - the top level package is really the only one which knows about these adapters and imports them - it then presents an interface to the world which is under its namespace, so the only worry for uniqueness is the top level pkg name really.

grey-area 14y ago

Because packages are namespaced by user, and it's easy to rename imports, I don't worry about choosing obvious names - that's only a problem if it is popular and used by more people than me anyway :) So I'm using obvious names, with the pkg (say core) in one folder, and subpkg in the subfolder named adapters. "github.com/user/core" this has a few .go files in it to split things up into different concerns, and a subpackage with adapters (again with a few files), imported with: "github.com/user/core/adapters" and using adapters.XXX in the core code. You can also do this: import ( mypkg "github.com/user/core/adapters" ) and use mypkg.XXX to refer to the subpackage, so you're not tied to the folder names for package import names, that's just the convention, and if someone needs to rewrite the name on import, they can do so.

lobster_johnson 14y ago
True, although it gets annoying having to "rename" a package like this. If it's a package you use everywhere in your project, it gets old fast; canonical, author-defined names are always the best option.
- grey-area 14y ago
  Yes, it could be a pain unless it was just imported in one or two files. In practice though I've not found collisions in package names to be an issue, simply because of the layering of packages - the top level package is really the only one which knows about these adapters and imports them - it then presents an interface to the world which is under its namespace, so the only worry for uniqueness is the top level pkg name really.