# Implicitly loaded modules in the future?

**URL:** <https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646>\
**Category:** Internals & Design\
**Tags:** question, module, code-organization\
**Created:** [June 9, 2021, 8:58pm UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646 "2021-06-09T20:58:00Z")\
**Posts on this page:** 1\
**Showing post:** 44

<div class="post-metadata">

**Author:** ![patrick-kidger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/patrick-kidger/32/20378_2.png) [@patrick-kidger](https://discourse.julialang.org/u/patrick-kidger)\
**Post date:** [June 10, 2021, 2:20pm UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646/44 "2021-06-10T14:20:07Z")

</div>

> [@PetrKryslUCSD](#):
>
> It seems to me that requiring users to care about files is counterproductive. If a user needs some functionality, it should be in a package, and no include is needed. Developer is free to organize things into files, based on the DAG representation of the code (in the developer’s head), but why would a macro be needed for that? Just decide on what should the physical representation into files should look like a then use `import` . In my mind files and modules are independent concepts. I could have organized my package as a single giant file, but the modules would work just as well as when I keep it one module per file.

This approach doesn’t scale as well. An `include()`/package-based approach is:

- Heavyweight, requiring the creation of a package at every branch point in the code dependency DAG. That’s a lot of overhead just for some helper file.
- Requires a developer to look up `O(n)` code in the size of the codebase `n` to track the dependencies of any individual piece of code. This is as opposed to just `O(log n)` in a well-designed file-based approach.
- Implicit. Within each package, dependency DAGs are held only in developer’s heads, instead of being explicitly written down. Harder to on-board people / easier to make mistakes.
- open to spooky-action-at-a-distance. It is possible for construct natural examples in which changes in one set of files will affect method resolution in unrelated parts of the code.

---

_[View the full topic](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646)._