_由 gfredericks 评论
我认为没有干净的解决方案可以解决你提到的问题,这也是为什么我没有看到明显的解决方案。
我在创建{{large-integer}}和{{double}}生成器时遇到了这个问题,并决定创建两个生成器:{{large-integer}}具有默认行为,而{{large-integer*}}是一个接受选项并返回生成器的函数。
事后再来看,我不确定这是否是最优选择,因为它有些令人困惑。我向David MacIver询问了他在hypothesis(一个类似Python库)中是如何处理的,他说他没有任何原始生成器,只有返回生成器的函数(有时不带参数)。我喜欢这种方式的一致性,但它显然会对test.check造成很大的破坏性变化(尽管有一些巧妙的技巧可以保留向后兼容性)。
这个问题比这个工单要大。关于你提供的代码,我认为我更倾向于那些具有选项映射的API,类似于{{gen/set}},而不是位置参数。
现在我开始思考这个问题,我开始对一个大型的破坏性API变革着迷,该变革使用一些技巧来保持几个版本的向后兼容性,以便清理大量不一致性。但又一次,这比这个工单要大。
如果我们想不出一个干净的中期对策,在[gfredericks/test.chuck|
https://github.com/gfredericks/test.chuck]的接受标准会宽松得多 ☺。