Say I’m writing a package P, which contains two sub-modules M1 and M2. Both submodules share some common codes, so I extract the common codes and wrap it in another sub module C
I decide to split the codes into four files:
the root module file P.jl
module P
include("M1.jl")
include("M2.jl")
end
M1.jl
module M1
include("C.jl")
...
end
M2.jl
module M2
include("C.jl")
...
end
C.jl
module C
...
end
Then the topology of the package P becomes
P->M1->C
P->M2->C
And the content of C.jl appears two times in the final P.jl (?). Seems to be rather noisy.
Is there a better method to arrange the files?
Or is there any guides about how to arrange the files?
The first thing to do is to once more question yourself whether you really benefit from the split into submodules. If the answer is yes, maybe try something with the structure
P.jl:
module P
include("C.jl")
include("M1.jl")
include("M2.jl")
end
Any reason not to have the common parts directly within module P?
(P.jl as proposed by @GunnarFarneback, but omit the using ..C statements in the module files and the module block in C.jl.)
Including C.jl two times is not only noisy, but may also cause confusion or bad error, for example, if C.jl has type “TestType”, and one includes “C.jl” in “M1.jl” and “M2.jl” then “TestType” is not unique in “M1.jl” and “M2.jl” and we have two different “TestType”.
In my experience, I usually do all the “include” in the outter most module and the inner modules will only use “using .“ where the number of dots depends on the hierarchy.
This is a good question.
Do submodules have access to the enclosing scope of parent modules?
If so, what are the pros/cons of this vs including module C?
For an example of exactly the kind of problem that @congvan is correctly pointing out, see this recent post: I'm confused with types names . Including a file multiple times will result in different types with the same name and is likely to create all kinds of confusion.