是否使用spec来获得诸如静态类型一样的优势？有哪些局限性？

Question

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

在静态语言中，通过在代码中声明因此而减少编写测试的努力，以及推理允许一些注解渗透——说到Clojure的spec特性，似乎可以用来达到类似的结果。

是否使用spec来获得诸如静态类型一样的优势？有哪些局限性？

编辑：我重新整理了这个作为问题，并把我的一些想法移至gist...

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

Answer 1

你能总结一下你在这里实际上问的是哪个问题吗？

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

Comments

感谢您花时间阅读。

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

也许我的方法太过宽泛了。

这是否是讨论成功技巧和应避免之事的不当地方？

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

---

和Quora和StackOverflow一样，这是一个提问和获得答案的地方——但我实在不知道你在问什么问题。我认为如果你能编辑它使你提出的问题更聚焦，这样人们就会清楚他们应该回答什么，这将有所帮助。

我认为clojure.spec与静态类型无法相提并论，因此，即使新的标题以问题形式表述，我也不知道该怎么回答（我们自1.9.0周期的早期alpha构建开始，就是clojure.spec的重度使用者）。

---

重新加工并将我的想法移动到一个gist...

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

---

不错，问题现在清晰了。我很期待看到你将获得什么答案！

---

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

---

完成了。谢谢。

Answer 2

由于你的问题还没有得到回答，我将在这里贴上我的最新博客文章链接

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

正如你在帖子中看到的，它最初是作为Quora上关于Spec的更开放的问题的回答而写的。