Say I have a package that neatly separates into a few “units” (i.e. chunks of more or less independent code). The units do depend on some overarching constants and functions, as well as each other’s outputs (so unit 2 receives unit 1’s output).
Now, I can either:
keep each unit in its own .jl file, and include("unit1.jl"), inside the main module, OR
keep each unit in its own .jl file, make that a module of its own, include("Unit1.jl"), and using Unit1, inside the main module.
In terms of namespace there is no overlap (that I can’t deal with), in fact, I sometimes need to import ..SomeType.
Are there any advantages to keeping each of the “units” as their own (sub)modules or should I just keep them as is (a bunch of types and functions in the same (main)module)?
If the only place that those units are used are within your (main)module, then you are probably fine without making it into a module, since now instead of one statement of include("unit.jl") you now have multiple statements to just accomplish the same task:
include("unit.jl")
using Unit
which is more convoluted, if it is not needed.
However, if you have a very cluttered namespace, then it might be of advantage to indeed place it into its own module and use the using syntax. Then when you call using, all of the functions that are not exported will now be hidden and tucked away. So it depends on whether you experience conflicts, but this also requires you to put more effort into determining what functions need export statements and how to manage.
So putting it into a module is a tradeoff that adds a bit of extra maintenance to your package work, which might be unnecessary if it is not needed due to namespace issues within the scopes you intend to use it for.
Thanks. I was partly worried I was missing out on some speed up I could get from putting them into modules. But the code is a lot more straight forward now, with all the “units” in the same module. Thankfully, my namespace is fiiiiiiine…!