优先考虑使用index-of核心函数而非互操作调用

Question

Clojure核心可能会考虑一个函数

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

这将有助于您在当前必须编写的情况下

(.indexOf something :foo)
这会很丑陋，因为您需要了解诸如PersistentVectors或其他类型的实现。

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

我意识到index-of不是一个理想的性能相关函数，但它有它的用例。

这个函数应该被推广成一个返回（懒）索引序列的函数，而不仅仅是第一个索引吗？

Answer 1

clojure.string/index-of 函数对字符串进行了处理。对于数据集合（colls），过去曾考虑过类似的议题但被拒绝（在我的脑海中，[https://clojure.atlassian.net/browse/CLJ-2056](https://clojure.atlassian.net/browse/CLJ-2056) 是其中一个，但我想可能还有其他）。

Comments

> 线性搜索（尤其是嵌套线性搜索）的使用导致了性能较差。

是的，我明白了，但我看到人们使用 `.indexOf` 混合操作，这让我有些烦恼，因为它依赖于内部实现。

---

将这一话题引向一个稍微不同的维度——回想起2010年，一位Clojure的贡献者在Google Group中回复说，

"因为95%的情况下使用.indexOf是为了检查元素是否存在于集合中（如果只是偶尔，则可以使用(some #(= item %) coll))，所以没有将其包含在核心库中是为了推广更适合的数据类型（如集合、映射）。"

---

我的立场是标准化：我不喜欢在babashka中支持向量上的.indexOf，因为这暴露了实现细节，所以最好有一个核心函数来处理这个问题，或者实际上推荐使用.some方法。

---

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