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

Question

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

我一直在查看模块，他们似乎使用的不仅仅是使用模块关键字来代替部分代码。

更好的方法是什么？

Answer 1

Julia有3个等级＆＃34;你可以放置代码的地方＆＃34;

• include＆＃39; d个文件
• 的子模块
• 软件包 - 我们的目的只有1个（非子）模块。

鉴于我来自python，我习惯成为子模块的忠实粉丝。

但是朱莉亚的子模块并不是那么好。 根据我的经验，使用它们编写的代码往往会让开发人员和用户视角都很烦人。 它干得不干净。 我已经从至少一个软件包中删除了子模块，并切换到普通include s。

Python需要子模块，以帮助处理其命名空间 - ＆＃34;命名空间很棒，让我们做更多的事情＆＃34;。 但由于多次发送，julia不会耗尽函数名称 - 你可以重复使用相同的名称，使用不同的类型签名，这很好（甚至是好的）

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

我发现子模块出错了：

说你有：

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

通常会做using A.B 但是你可以做错using B，因为B可能在你的LOAD_PATH中名为B.jl的文件中。 如果您这样做，那么您想要访问类型C。 如果您已完成using A.B，则在输入语句A.B.C时，最终会输入B.C()类型。 但如果您错误地完成了using B，那么B.C()会为您提供类型B.C。 此类型不兼容，其功能（因为它们正确using）期望为A.B.C。 它只是有点乱。

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

Base是使用子模块的朱莉娅代码的唯一主要部分之一（我知道）。甚至Base也将很多这些推入了julia 0.7的单独（stdlib）包中。

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