并不是,还想完全如此。kondo的类型检查系统有点草率。比如,每当它需要进行条件类型检查时,它必须插入一个自定义函数。
Kondo有一个针对core.into的自定义函数,它指定返回类型与传递给它的第一个参数类型的相同。已经在他们的JIRA板上有一个任务要在另一个函数中添加它,而且它也没有在诸如inc函数等各种其他函数中保持一致。如果你将一个整数传递给inc,Kondo不知道输出是否仍然是整数。
也就是说。
此代码:(nth [1 2 3] 1.5) 在 kondo 中引发错误(顺便说一下,nth 对非整数也是有定义的)
但此代码(nth [1 2 3] (inc 0.5))则没有错误。
如果这种情况持续下去,kondo 最终将不得不包含大量逻辑,而这些逻辑并不一定属于它们的代码库。
如果用户想要实现或扩展类似逻辑,这将非常困难。没有简单和易于理解的方式来定义它。我希望 spec 能够成长为一个标准,以便开发者在他们自己的代码库中以 TypeScript 的方式编码必要的类型逻辑。例如,如果您的代码库中定义的集合为整数的集合,或者为数据库自定义类型的集合,那么这将传达给 kondo,它就能够对该集合进行逻辑处理,并在进行了几次转换后查看是否会出现失败。Spec 和 Malli 已有一些系统来完成这项任务,但 kondo 还没有完成所需逻辑。
我不确定进行此类分析的适当逻辑属于 kondo 本身,还是属于 Clojure 代码库中的某个地方,因为它是完全依赖于 Clojure API 的。我也不确定 spec 还是 spec2 是存放它的正确位置。这就是为什么我这里提出这个问题。