Looking at the diagram for the SQLite VFS page I didn't think I was going overboard with designing my driver around 3 packages: https://sqlite.org/vfs.html
One layer wraps SQLite C API, below it lives a pure Go VFS, and above all that database/sql driver.
Even this coarse split (with a collection internal packages, the bigger one of them “utils”) is enough to need various band-aids to accommodate the impossibility of circular dependencies.
I honestly don't think it helps much.
At the module level, there are obvious benefits from the impossibility. Just like all the pain around v2 modules can be justified, even if I find it annoying.
When packages are also the only layer at which you can enforce visibility, it becomes worse.
Comments
Looking at the diagram for the SQLite VFS page I didn't think I was going overboard with designing my driver around 3 packages: https://sqlite.org/vfs.html
One layer wraps SQLite C API, below it lives a pure Go VFS, and above all that database/sql driver.
Even this coarse split (with a collection internal packages, the bigger one of them “utils”) is enough to need various band-aids to accommodate the impossibility of circular dependencies.
I honestly don't think it helps much.
At the module level, there are obvious benefits from the impossibility. Just like all the pain around v2 modules can be justified, even if I find it annoying.
When packages are also the only layer at which you can enforce visibility, it becomes worse.
See the last case of how to handle circular dependencies.
Ports are special cases. Always are.