Should we finally refactor the code into submodules? #74
Description
I held off on this from the beginning because (i) I don't like the way modules work in Julia, especially submodules, and (ii) I don't think it's a good idea to pre-specify too much structure, but rather allow it to grow somewhat organically.
That being said, despite being a fairly simple (and not entirely functional...) land model, Terrarium has already grown rather large. The Terrarium namespace already has 158 unique identifiers, excluding imported names. If you include non-exported names (i.e. names(Terrarium, all = true), that number jumps to over a thousand 😅 .
This was, of course, inevitable, and submodules would be one way of controlling this complexity and increasing discoverability. At the moment, tab-complete on the Terrarium module is almost useless due to how big it is.
So this leaves us with two key questions:
-
Do we bother going down this route of defining submoduels? What are the benefits and what are the costs?
-
If we do introduce submodules, what should the module structure look like?
I will leave (1) to the discussion. Regarding (2), I would start by emphasizing one very important rule that must not be broken:
Under no circumstances should the top-level module be imported into the submodules.
Experience has taught me that this is universally bad. It's a clear anti-pattern in Julia and the language shouldn't even allow it. You very quickly end up with weird situations where the required include and import order becomes very confusing and brittle, since only names defined up until the point the submodule is included are visible to the submodule when doing using ParentModule.
As such, we would probably need some kind of "core" submodule that defines all of the abstract types and method interfaces, as well as core numerics like grids, kernel launching, mathematical utilities, etc.
An alternative and perhaps more standard Julia pattern would be to create a completely separate top-level module (package) called TerrariumCore that holds all of these things.
Happy to hear ideas on the best way forward here. Note of course that this is not a top priority issue, I think we can still survive with the single, top-level module for the time being.