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

Question

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

我一直在看模块,他们似乎使用的不仅仅是实际使用模块关键字来代替部分代码.

有什么更好的方法？

Answer 1

Julia有3个级别的"你可以放置代码的地方"

• include'd档案
• 子模块
• 包 - 为了我们的目的,它只有1个(非子)模块.

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

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

Python需要子模块来帮助处理它的命名空间 - "命名空间很棒,让我们做更多的事情".但由于多次调度,julia不会耗尽函数名称 - 你可以重复使用相同的名称,使用不同的类型签名,这很好(甚至好)

通常,子模块允许您将每个子模块彼此分离和分离.但在这种情况下,你为什么不使用完全独立的包？(有共同的依赖)

我发现子模块出错了:

说你有:

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

人们通常会这样做using A.B
但是你可以做错,using B因为B可能B.jl在你的LOAD_PATH中调用的文件中.如果您这样做,那么您想要访问类型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)包中.

简而言之,如果您正在考虑使用子模块,请检查它是否是您从其他语言带来的习惯.并考虑您是否只想发布另一个单独的包.