缺少dissoc-in

Question

尽管存在assoc-in，但clojure.core中没有dissoc-in。
的确，可以使用update-in和dissoc构建dissoc-in，但这也是反对assoc-in的一个论据。
提供assoc-in的快捷方式时，也应提供dissoc-in，以保持一致性。
实现与assoc-in相似。

Answer 1

评论者：alexmiller

我们必须考虑除了map之外的其他向量或关联数据结构。我也宁愿不使用标志，而是将其留给可变数量的来删除多个。

使用类似下面的等效表达式

(update-in [{:foo 1}] [0] dissoc :foo)

我们就会剩下一个{{[{}]}}，因此现有的方法也留下了空集合。

我还查看了一些现有的dissoc-in实现 - core.incubator, taoensso.encore, clj-http, medley, useful, plumbing等。大多数只与一个key-path一起工作，并留下空集合 - 这些似乎主要源自incubator版本。Encore版本通过将key path与要删除的最终叶子键分开来处理多个路径（可变数量）。Medley、useful和plumbing版本仅限于map，并删除空map。

我难以想象我们会在core中创建一个特定的map版本（因为其他-in函数是通用的），因此我得出结论，我们需要一个保留空集合的dissoc-in。考虑到这一点，我不确定dissoc-in是否比update-in + dissoc提供足够的价值，以至于值得在此处将其添加到core中，尤其是它已存在于多种实用库中（在许多情况下，语义有所不同）。这样，我们可能会打断（或至少不便）许多现有dissoc-in使用者。我将留此问题供评论，但我的想法是拒绝这个增强功能。

Answer 2

评论者：alexmiller

是的，尽管我认为在更新案例中，这些因素平衡的方式不同。在更新中，有更少的实现，并且它们与我们所提议增加的内容相匹配。因此，它们为用核心功能替换现有内容创造了潜在的可能性。

我认为常见的工具库实现（flatland/useful/plumbing）实际上满足了不同的需求——只在map上更新、删除路径。因此，如果目标是覆盖常见的使用情况，那么我们就需要在map上工作，并删除留下的空路径。然而，我认为这与其他核心-in函数有所不同。我想可能有一个中间点来做路径删除，但使其可在map之外工作——这将满足工具库所示的需求，同时也像其他-in函数一样通用。如果你需要留下空集合，你可以做你现在所做的那样——update-in+dissoc。

Answer 3

评论者：jafingerhut

2012年9月13日的补丁clj-1063-add-dissoc-in-patch-v2.txt取代了2012年9月7日的001-dissoc-in.diff。它修正了一个错误（在文档字符串中遗漏了最后的"），并为新函数添加了一个测试用例。

Answer 4

评论者：bronsa

感谢修复，Andy

Answer 5

评论者：jafingerhut

这个提议的dissoc-in应该与clojure.core.incubator中的dissoc-in进行比较，我刚遇到了它。我看到它们看起来不一样，但还没检查它们是否有行为上的不同。

https://github.com/clojure/core.incubator/blob/master/src/main/clojure/clojure/core/incubator.clj

Answer 6

_评论者：bronsa_

clojure.core.incubator中的dissoc-in递归删除空map

user=> (clojure.core.incubator/dissoc-in {:a {:b {:c 1}}} [:a :b :c])
{}

而在这个补丁中的dissoc-in没有这样做（正如我所期望的）

user=> (dissoc-in {:a {:b {:c 1}}} [:a :b :c])
{:a {:b {}}}

Answer 7

stu发表的评论：

请在孵化器中完成这项工作。

Answer 8

andrewhr发表的评论：

保留空路径真的是最期望的操作吗？我认为，由于{{assoc-in}}/{{update-in}}在整个过程中创建路径，这种行为看起来像是真正的“双生”。

可能发生什么坏事情，让{{nil}}玩笑不能很好地处理？这些问题对于{{dissoc-in}}用户而言可能会过于隐晦吗？

Answer 9

评论者：alexmiller

补丁中的测试过于简单。应该测试多级、记录、向量等。

Answer 10

[email protected]发表的评论_

正在测试"clj-1063-add-dissoc-in-patch-v2.txt"。


(dissoc-in {} [:a :b :c])
=> {:a {:b nil}}


这种行为相当意外。孵化器版本没有这个问题，尽管它会删除空映射。

我正在为这个补丁开发测试（以及可能的新dissoc-in），但还不清楚是否应该保留空路径或删除它？我不在乎哪一种方式，尽管我倾向于同意安德鲁·罗萨的观点，即保留它们更对称。

Answer 11

[email protected]发表的评论：

@alex，您是否希望保留空路径或删除？两种方式都可以接受，尽管权衡之下，我稍微偏向于保留。一旦我知道您想要走的方向，我可以为该方向编写测试。

Answer 12

评论者：alexmiller

相互之间的权衡是什么？

在人们使用dissoc替代品的地方（例如，使用update-in配合dissoc等），他们期望什么行为？

Answer 13

_评论由：michalmarczyk_

如果我们只想处理嵌套在map中的map……，我可能更喜欢移除空子路径。

然而，如果我们希望在途中接受向量，那么保留空路径在这种情况下可以提供清晰的语义。


(dissoc-in [{:foo 1}] [0 :foo])
;= [{}]


相反，移除空路径可能会引起必须解决的问题，这些问题必须通过限制移除行为仅为map或者当向量的子路径变为条目时引发异常来解决。两种方法似乎都不是最优的。

Answer 14

评论由：michalmarczyk

此外，我们可以从技术上接受一个标志来决定是否应该移除空路径，并让用户确保只有在没有向量的情况下才传递{{true}}。不过，我并不太喜欢这种做法，因为它在我看来，额外参数的更自然用途是为dissoc提供更多路径以匹配变元{{dissoc}}和{{dissoc-in}}语义（参照CLJ-1771）。

Answer 15

评论者：bronsa

同样的论点也可以用于包括update。update和dissoc-in可以在多个util库中找到，这应该表明人们并不满意仅仅使用update-in + dissoc。

当然，将其添加到核心可能会在使用某些库时引发警告（这不会破坏任何事情，与update有关的AOT错误已经被修复），但这并不真正是个大问题；这些库的新版本将很快发布，即使没有那么快，警告也并非世界末日。