优先考虑indexOf核心函数而不是互操作调用

Question

Clojure核心可能考虑一个函数

(defn index-of [coll elt] ...)

这将帮助在你目前需要编写的情况下

(.indexOf something :foo)
这很丑陋，因为你需要了解关于e.g. PersistentVectors或其他类型的实现。

index-of函数可以用于clojure.lang.Indexed、java.util.List和java.lang.String实例，也许可以通过协议进一步扩展。

我明白index-of在性能方面不是一个理想函数，但它有其用例。

这个函数应该被推广为一个返回(懒)索引序列而不是仅返回第一个的函数吗？

Answer 1

clojure.string/index-of已经存在，用于处理字符串情况。对于集合，已经考虑并拒绝了类似的请求（我脑海中想到的是https://clojure.atlassian.net/browse/CLJ-2056，但我想可能还有其他）。

Comments

使用线性查找（特别是嵌套线性查找）会导致性能较差

是的，我明白了，但我看到有人使用`.indexOf`互操作性（Interop calls），这让我有些烦恼，因为这个依赖于内部实现。

---

为了从这个话题的角度略微有些不同 -- 回到2010年，一名Clojure的贡献者在Google Group上做了回复：

“由于95%的时间中.indexOf是用来检查一个元素是否在集合中（如果是一个独立的操作，可以使用(some #(= item %) coll)），所以他没有包含在核心中用于推广更合适的数据类型（如集合、映射）。”

---

我的观点是标准化：我不希望在babashka中支持向量上的`.indexOf`，因为这会暴露实现细节，所以最好有一个核心函数来做这件事，或者确实推荐使用`some`方法。

---

“some” 方法则会告诉您一个元素是否属于这个集合，但它不会告诉您索引（基本上，它是在询问谓词是否针对集合中的某个元素返回 true，并相应地返回 true 或 nil）。但这并不能告诉您元素在集合中的位置。我多次想在核心功能中实现一个覆盖所有顺序集合的 `index-of` 函数（任何可以响应 `nth` 的东西）。通常我会用这个函数用在统计类型的例程中，例如，一个给定的数据值代表一个百分比。所以首先对集合进行排序，找到元素索引，然后将索引除以元素的个数等。是的，它的时间复杂度是线性的。但这并没有阻止 `clojure.string/index-of` 有用。是的，对于程序实现二分查找来说更好，尤其是对于排序后的数据。这也会在核心函数中很有用（仅限向量）。