Replies: 1 comment
-
|
Both Go and V do this by design. Imports are dependencies of a file, not magical state of the whole module. It makes each file self-describing. When you open file_b.v, you can immediately see what external modules it depends on. You don't have to hunt for a central imports file and wonder which imports are available by side effect. It improves readability, tooling, refactoring, dependency analysis, and compile determinism. The cost is repetition. vfmt/gofmt take care of this automatically. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
For example:
Currently, each file must repeat its own
importstatements even when all files belong to the same module.Is there a recommended way in V to avoid repeating imports across files of the same module?
Something similar to Julia's
include()behavior, or a module-level import shared by all files?If not, is there a design reason why imports are intentionally file-scoped rather than module-scoped?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions