gpt4 book ai didi

Haskell 模块命名约定

转载 作者:行者123 更新时间:2023-12-03 08:49:29 27 4
gpt4 key购买 nike

我应该如何为程序而不是库和 命名我的 Haskell 模块将它们组织成层次结构 ?

我正在制作一个名为 Luminosity 的光线追踪器。首先我有这些模块:

Vector Colour Intersect Trace Render Parse Export

每个模块本身都很好,但我觉得这缺乏组织。

首先,我把每个模块都放在 Luminosity 下。 ,例如 Vector现在是 Luminosity.Vector (我认为这是 haskell 程序的标准?)。

然后我想:Vector和Color是独立的,可以复用,所以应该分开。但是它们太小了,不能变成图书馆。

他们应该去哪里?已经有(在 hackage 上)一个 Data.VectorData.Colour ,所以我应该把它们放在那里吗?或者这会导致混淆(即使我将它们与其他本地进口组合进口)?如果没有,应该是 Luminosity.Data.VectorData.Luminosity.Vector ?我很确定我已经看到两者都使用过,尽管也许我只是碰巧看到了一个使用非常规结构的项目。

我还有一个简单的 TGA 图像导出器 ( Export),它可以独立于 Luminosity。正确的位置似乎是 Codec.Image.TGA ,但同样,应该 Luminosity在某个地方,如果是,在哪里?

如果 Structure of a Haskell project就好了或其他一些维基解释了这一点。

最佳答案

除非你的程序真的很大,不要按层次结构组织模块。 为什么不?因为尽管计算机擅长等级制度,但人却不擅长。人们擅长有意义的名字。如果您选择好的名称,您可以轻松地在一个平面 namespace 中处理 150 个模块。

I felt like [a flat name space] lacked organization.



等级组织本身并不是目的。为了证明将模块分成层次结构是合理的,您需要一个理由。好的理由往往与信息隐藏或重用有关。当您引入信息隐藏时,您就完成了库设计的一半,而当您谈论重用时,您实际上是在构建库。将一个大程序变成“小程序加库”是软件进化的一个好策略,但看起来你才刚刚开始,而且你的程序还不够大,无法以这种方式进化。

这些问题在很大程度上与您使用的编程语言无关。我建议阅读 David Parnas 的一些关于产品线和程序系列的著作,以及 Matthias Blume 的未获认可的论文 Hierarchical Modularity .这些作品将为您提供一些关于等级何时开始服务于目的的更具体的想法。

关于Haskell 模块命名约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11594983/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com