Right. From this Stack Exchange answer, here’s a definition of module:
- encapsulates code and data to implement a particular functionality.
- has an interface that lets clients to access its functionality in an uniform manner.
- is easily pluggable with another module that expects its interface.
- is usually packaged in a single unit so that it can be easily deployed.
Note that there is no mention of dependency resolution or code loading. As you can see, there is nothing improper about Julia modules, so the title of this thread is definitely misleading.
The focus of this discussion is on dependency resolution/code loading, which is somewhat orthogonal to the use of modules as namespaces.
I’ve argued before that using submodules in Julia is an anit-pattern, because what one should be doing is overloading generic functions. I would much rather have
As @jonathan-laurent admitted in his Github post, using a lot of sub-modules adds a lot of boiler plate to a package, since you’re constantly importing and exporting types and functions from various submodules within your package.
Some folks have argued for the file-module correspondence (each file is automatically a module). I strongly oppose this. Since I don’t use submodules in my Julia packages, I would be forced to put the entire codebase for a package into a single file.
If future Julia code ends up looking like the following, then I’m out.