我经常发现自己处在一种情况,我真的不在乎我是否有矢量或地图:
[:foo :bar :baz :qux]
{0 :foo, 1 :bar, 2 :baz, 3 :qux}
重要的功能(get,assoc等)同时适用于两者.有些dissoc人不喜欢向量,但他们有充分的理由不这样做.
但是,我根本不明白为什么keys并且vals在地图上工作而不是向量.有没有什么好的理由可以解释为什么它们没有像这样实现(或者更优雅的多态解决方案)呢？
(defn keys [m]
(if (vector? m)
(seq (range (count m)))
(clojure.lang.RT/keys m)))
(defn vals [m]
(if (vector? m)
(seq m)
(clojure.lang.RT/vals m)))
如果没有充分的理由,我怎样才能尝试在标准Clojure中实现？
我认为这是一个有价值的有效想法.
应该使用哪些函数以及哪些函数应该是错误的问题很难划清楚线.一方面,语言可能过于宽松(JavaScript？),以至于它可以让你伤害自己.在另一端,它可以是如此规范,你没有强大的抽象组成(C？).
在这种特殊情况下,我们正在讨论在编写需要映射的代码时检测错误的能力,但是传递了一个向量; 反对能够编写更多通用代码的好处.就个人而言,我喜欢它被视为一个错误,因为我有时会将错误类型的集合传递给一个函数,并且更喜欢它爆炸而不是做某事.
我会发现调用keys一个向量很困惑,因为一个向量没有键,它是可索引的.对我来说,他们是不同的东西.因此,如果我编写调用keys向量的代码,则可能是错误.如果我真的想要一个与向量计数大小相同的范围,我会明确地写出来.如果我想要一个可以处理地图和向量的函数,我会使用条件类型来选择键或范围计数.显然这些只是我的偏好,但对我来说,它们是不想keys在矢量上工作的重要原因.特别是我想要发现错误的原因.
但是,完全可以理解的是,您更喜欢使用向量,看它们是否通过索引关联.
至于应该dissoc工作,其他人可能会声称为什么不呢？(dissoc [1 2 3] 0) -> [2 3])存在性能问题,因为您无法删除O(1)中的元素,如果Clojure采用rbb-vector则不会.有时你必须做这个操作非常方便.这是人们需要做的事情,在Clojure中非常丑陋和不透明!我们俩都不希望这是一个功能,但我敢打赌它在某些情况下会非常优雅.但这并不是技术限制的情况,我们只是喜欢这种方式.
Clojure有一个公开的贡献过程,可以归结为:讨论你在Clojure Dev Google小组上与其他人一起尝试做些什么.他们可能会提供意见和建议,从而带来更高质量的变更和更顺畅的提交流程.提交CA后,您可以通过JIRA提交补丁.
任何人都可以向Clojure提交错误或增强请求.任何签署了贡献者协议的人都可以提供补丁或改进门票.筛选员已被授予通过(部分)过程阶段移动票证的能力.BDFL - Rich Hickey是Clojure内容的创造者和仁慈的独裁者.Stuart Halloway还具有特殊级别的访问权限,通常会向Clojure提交补丁.
如果您认为这对Clojure来说是一个很好的改变,我建议首先在Clojure Group中讨论它,以获得对该想法的一些支持,然后将其带到Clojure Dev Group.一般来说,当有支持的文物时,你的想法会得到最好的接受,例如"这是一个很好的用例,它展示了价值"和"这里是一些讨论,其他人都渴望相同的价值主张".