3 ms·
This is one of the things that frustrates me about go. They started with this very good advice and then took it one step stupider: Disallowing circular imports.
by kstenerud 6y ago
This is one of the things that frustrates me about go. They started with this very good advice and then took it one step stupider: Disallowing circular imports.
Why is this bad? It makes it impossible in many situations to locate your public API at the top level. Let's say you have a Widget interface and APIs to do things with those Widgets. Eventually your library gets complex enough that you want to separate functionality into subdirs. Now you have a problem: You can't access the definition for Widget from the subdir because importing the top level would create a circular import!
The only way to get around this problem is to have no code at the top level, and put your public API in a subdir. Just be sure to do this when first starting your library or you'll have to break things.
- caylus 6y agoYou can deal with that issue by defining things in a submodule, then importing and re-exporting them in the top-level (e.g. `type Foo = subdir.Foo`). That even lets you move things into the submodule without breaking callers. Other submodules can then import from the submodule rather than the top-level.
- xiphias2 6y agoThis is how libraries are exported inside Google (use /public subdir for the public interface), and I guess with Go this got into the language. But I think Go made much worse things than this :)