Julia 代码封装。这是一个普遍的好主意吗？

Question

Julia 用户使用 module 关键字将功能封装到自己的模块中是不是很常见？

我一直在研究模块，它们似乎在部分代码中使用 include 比实际使用 module 关键字更多。

有什么更好的方法？

Answer 1

Julia 有 3 个级别的“可以放置代码的地方”

• 包含的文件
• 子模块
• packages -- 就我们的目的而言，它恰好有 1 个(非子)模块。

我曾经是子模块的忠实粉丝，因为我来自 python。

但是 julia 中的子模块并不是那么好。 根据我的经验，无论是从开发人员的角度还是从用户的角度来看，用它们编写的代码都会很烦人。 它只是不干净。 我已经从我的至少一个包中删除了子模块，并切换到纯 includes.

Python 需要子模块来帮助处理它的命名空间——“命名空间很棒，让我们做更多”。 但是由于多次分派(dispatch)，julia 不会用完函数名——你可以重用相同的名称，使用不同的类型签名，这很好(Good even)

通常，子模块允许您将每个子模块彼此分离和解耦。但在那种情况下，你为什么不使用完全独立的包呢？ (具有共同的依赖关系)

我发现子模块有问题:

说你有:

 - module A
     - module B (i.e A.B)
         - type C 

人们通常会使用 A.B
但是你可能会错误地using B，因为B 可能在你的LOAD_PATH 中一个名为B.jl 的文件中。 如果你这样做，那么你想访问类型 C。 如果你已经使用 A.B，当你输入语句 B.C() 时，你最终会得到一个类型 A.B.C。 但是如果你错误地使用了B，那么B.C() 会给你类型B.C。 而且这种类型与期望为 A.B.C 的函数(因为它们使用正确的using)不兼容。 就是有点乱。

reload("A.B") 也不起作用。 (但是 reload 通常效果不佳)

---

Base 是使用子模块的主要 julia 代码块之一(据我所知)。甚至 Base 也被推送到 julia 0.7 的单独 (stdlib) 包中。

简而言之，如果您正在考虑使用子模块， 检查这不是你从另一种语言带来的习惯。 并考虑您是否只想发布另一个单独的包。