我有一个阴谋集团包 https://github.com/acfoltzer/nbt导出一个类型NBT https://github.com/acfoltzer/nbt/blob/master/src/Data/NBT.hs这可能对其他开发人员有用。我经历了定义一个的麻烦Arbitrary我的类型的实例，如果不将其提供给其他开发人员来测试他们集成我的工作的代码，那将是一种耻辱。
但是，我想避免我的实例可能妨碍的情况。也许其他开发者有一个不同的想法 https://stackoverflow.com/questions/5643360/how-do-you-override-haskell-type-class-instances-provided-by-package-code为了什么Arbitrary实例应该是。也许我的包对特定版本的 QuickCheck 的依赖可能会干扰客户端项目的依赖项，或者在客户端项目的依赖项中是不需要的。
我的想法（排名不分先后）是：
- 留下
Arbitrary类型定义旁边的实例，并让客户端处理隐藏实例或覆盖 QuickCheck 版本号。
- 使
Arbitrary实例同一包内单独模块中的孤立实例，例如Data.NBT.Arbitrary。整个包对 QuickCheck 的依赖仍然存在。
- 提供
Arbitrary实例位于完全独立的包中，以便可以将其列为客户端项目的单独测试依赖项。
- 有条件地包括
Arbitrary实例和主包中的 QuickCheck 依赖项，但前提是像这样的标志-ftest is set.
我已经在其他库中看到过所有这些的组合，但还没有找到关于哪种效果最好的共识。我想在上传到 Hackage 之前尝试将其正确。
基于没有太多具体经验，但对健壮性的普遍渴望，包依赖关系的指导原则也许应该是
各尽所能；根据每个人的需要。
最好将包的依赖关系保持在其基本功能所需的最低限度。这向我建议了选项 3 或选项 4。当然，把包裹砍这么多也是很痛苦的。如果选项能够表达所涉及的条件，那么选项 4 听起来像是一个明智的方法，它基于有效地使用语言来表达你的意思。
如果我们能够就需要按下哪个开关才能获得测试套件以及基本功能达成共识，那就太好了。
很明显，这里还有改进的空间。令人惊奇的是 Cabal 的工作效果如此之好，但它可以允许更复杂的“包”概念，也许是按照 SML 模块系统的方式。将依赖关系转换为函数类型，我们基本上可以编写
simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable
但人们可以想象更复杂的产品和功能组合，比如
fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)
在此之前，请选择最准确反映实际交易的选项。并告诉我们这一点，以便我们能够达成共识。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
