您是否使用spec来获取像静态类型一样的收益？局限性是什么？

Question

将静态语言中的类型声明视为一个测试，这个测试可以检测潜在的不兼容代码路径。例如，传入的数据与代码不兼容。

在静态语言中，测试工作因代码内联声明而减少，且推理允许几个注解渗透——尽管如此，Clojure的spec功能似乎也可以实现类似的效果。

您是否使用spec来获取像静态类型一样的收益？局限性是什么？

编辑：重新整理成了问题，并将我的想法移到了一个gist中...

https://gist.github.com/olivergeorge/9ae12592b49f8da4d911650b793dcbda

Answer 1

你能总结一下，您在这里真正提出的问题是什么吗？

我阅读了整篇文章，它似乎更像是一系列观察，而不是这里可以回答的问题。

Comments

感谢您抽出时间阅读。

我对探索spec检查在提供静态类型的一些好处方面的价值和限制很感兴趣。

也许我的方法太过宽泛。

这是不是鼓励讨论成功技术和要避免的事情的错误地方？

编辑：我已经更改了标题。

---

像Quora和StackOverflow一样，这是一个提问和获取答案的地方——但我实在无法知道你在问什么问题。我认为如果你能编辑一下让它更专注于你提出的问题，这样人们就能清楚他们回答的是什么，那会很有帮助。

在我看来，clojure.spec不能与静态类型相提并论，因此即使是新标题以提问的形式表述，我也不知道怎么回答（我们自从clojure.spec的第一个Alpha版本就开始重度使用它，在1.9.0周期早期）。

---

我在gist上重新整理并移动了我的想法...

https://gist.github.com/olivergeorge/9ae12592b49f8da4d911650b793dcbda

---

好了，问题现在已经很清晰了。我很想看看你得到的答案是什么！

---

我认为应该将要点链接到问题中。

---

完成了。谢谢。

Answer 2

由于你的问题还没有得到任何答案，所以我在这里附上我最近的一篇博客文章链接

https://corfield.org/blog/2019/09/13/using-spec/

从文章中，你会发现它最初是作为Quora上关于Spec的更开放的问题的回答而编写的。