# Purely functional modules

**URL:** <https://discourse.julialang.org/t/purely-functional-modules/89681>\
**Category:** Internals & Design\
**Tags:** modules\
**Created:** [November 3, 2022, 12:37am UTC](https://discourse.julialang.org/t/purely-functional-modules/89681 "2022-11-03T00:37:50Z")\
**Posts on this page:** 1\
**Page:** 2

<div class="post-metadata">

**Author:** ![Kirby\_Zhang](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kirby_zhang/32/36204_2.png) [@Kirby\_Zhang](https://discourse.julialang.org/u/Kirby_Zhang)\
**Post date:** [November 24, 2022, 6:10am UTC](https://discourse.julialang.org/t/purely-functional-modules/89681/21 "2022-11-24T06:10:47Z")

</div>

Assuming circular imports are disallowed, imported modules do not know about your namespace. Therefore, for any type you have access to, its owner cannot override methods defined in your own namespace; it’s safe to use any type in any manner you want, for functions in your namespace. This flexibility allows you to write “integration” modules, which freely use third party types to create new groupings of functionality.

The only restriction is you cannot define methods for functions in other (foreign) modules, led by other module’s types. You can lead a foreign method definition with your own type, or you must define the method in your own namespace.

I’m following these rules in my multi-module app. It’s small size relatively but hopefully this still makes sense over the long run.

 ![Julia fmodule method ownership chart v2](https://global.discourse-cdn.com/julialang/original/3X/9/b/9b2dd89612feab67b382c2bf1a4fb1fe2c11a234.png)

[Previous page](https://discourse.julialang.org/t/purely-functional-modules/89681.md?page=1)