Julia代码封装。这通常是个好主意吗？

对于Julia用户来说，使用module关键字将功能封装到自己的模块中是常见的事情吗

我一直在研究模块，它们似乎使用include而不是实际使用module关键字来表示部分代码

更好的方法是什么？

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

• 包括

  'd个文件
• 子模块
• 软件包——就我们而言，它正好有一个（非子）模块

鉴于我来自python，我过去非常喜欢子模块

但是julia中的子模块不是很好。 根据我的经验，用它们编写的代码无论从开发人员还是从用户的角度来看都很烦人。 结果就是不太好。 我已经从至少一个包中删除了子模块，并切换到普通的

include

s

Python需要子模块来帮助处理其名称空间——“名称空间很棒，让我们做更多的工作”。 但是由于多次分派，julia不会耗尽函数名——您可以使用不同类型的签名重用相同的名称，这很好（甚至很好）

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

我发现子模块出了问题： 假设你有：

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

人们通常会使用A.B

但是，由于B可能位于加载路径中名为
B.jl
的文件中，因此您可以错误地使用B
。
如果执行此操作，则需要访问类型
C
。
如果您使用A.B
执行了
，那么当您输入语句
B.C（）
时，您将得到一个类型
A.B.C
。
但是如果您错误地使用了B
，那么
B.C（）
将为您提供类型
B.C
。
而且这种类型不兼容（因为它们使用的是正确的
，
）预期为
A.B.C
。
只是有点乱

另外，
重新加载（“A.B”）
也不起作用。
（但是，
重新加载
通常效果不佳）


Base
是julia代码中唯一使用子模块的主要代码之一（我知道）。甚至连
Base
都被推到了julia0.7的独立（stdlib）包中

简而言之，如果您正在考虑使用子模块，
检查这不是你从另一种语言中养成的习惯。
如果你不想再发布一个单独的包裹，那么我就不明白这个问题了。你是否在询问人们对
在模块中包含
代码是否比直接编写代码更好的看法？我在问惯例是什么。使用module关键字将代码抽象到自定义模块中，使它们在技术上成为模块，或者只是将它们放在单独的文件中并包含它们。它们将一起使用。耦合组件一起放在一个模块中，但每个单独的组件可以驻留在不同的文件中。这是有道理的。非常感谢。