缺少dissoc-in

Question

虽然没有clojure.core/dissoc-in，但有一个assoc-in。
正确的是，可以用update-in和dissoc构建dissoc-in，但这也同样是反对assoc-in的一个论点。
当提供了assoc-in的快捷方式时，出于一致性原因，也应该有一个dissoc-in的快捷方式。
实现与assoc-in类似。

Answer 1

评论者：alexmiller

我们必须考虑向量或其他非映射的关联数据结构。我也不希望设置标志，而是希望它对可变数量开放以便一次性移除多个。

使用类似的语法

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

我们最终会得到{{[{}]}}，因此现有的方法确实会留下空集合。

我还查看了一些现有的dissoc-in实现，如core.incubator、taoensso.encore、clj-http、medley、useful、plumbing等。大多数只处理单个键路径，留下空集合——这些似乎大多源自孵化器版本。Encore的那个通过将键路径从最终要移除的叶键分离出来以处理多个路径（可变数量）。Medley、useful和plumbing的那些仅限于处理映射，并移除空映射。

我无法想象我们会将此作为特定的映射版本引入到核心（因为其他所有-in函数都是泛型的），因此我得出结论，我们需要一个可以留下空集合的dissoc-in。鉴于这一点，我不确定dissoc-in是否提供比update-in + dissoc更多的价值而值得添加到核心中，尤其是在它已经存在于各种实用库中（在许多情况下具有不同的语义的情况下）。这样我们可能会打破（或者至少不便）许多现有dissoc-in实现的用户。我将为此保留评论，但我的想法是暂缓此增强功能。

Answer 2

评论者：alexmiller

是的，尽管我认为在更新情况下，这些因素平衡的方式不同。在更新中，实现较少，它们与我们提议添加的内容相匹配。因此，它们为现有功能的替换创造了潜在的可能性。

我认为常见的实用工具库实现（flatland/useful/plumbing）实际上覆盖了一个不同的需求 - 在仅对map进行更新-in + dissoc + 路径删除。所以，如果目标是覆盖常见的使用，那么我们就需要在只对map进行操作的情况下，并删除留下的空路径。然而，我认为这与其他核心-in函数有一些矛盾。我想也许有一个折中的方案来做路径删除，但同时让它仅限于map之外的通用 - 这样就可以满足工具库所表明的需求，并且像其他-in函数一样具有通用性。如果您需要保留空集合，您可以像现在一样执行操作 - update-in+dissoc。

Answer 3

评论者: jafingerhut

补丁clj-1063-add-dissoc-in-patch-v2.txt，日期为2012年9月13日，取代了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])
{}

而在这个补丁中的不是的（如我所期望的）

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），但我还不太清楚是否应该保留或删除空路径？我不介意哪一种方式，尽管我倾向于同意Andrew Rosa的意见，即保留它们更为对称。

Answer 11

评论者：[email protected]

@alex，您希望保留还是删除空路径？两种方式都是可接受的，尽管从整体上看，我稍微更喜欢保留它们。一旦我知道了您的选择方向，我可以为这编写测试。

Answer 12

评论者：alexmiller

一个和另一个之间的权衡是什么？

在人们使用 dissoc-in 替代品（更新-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 都可以在几个工具库中找到，这应该表明人们不满足于仅仅使用 update-in + dissoc。

当然，将其添加到核心中将导致在使用某些库时出现警告（这不会破坏任何东西，导致使用 update 出现破坏的AOT错误已经修复），但我认为这不是什么大问题；这些库的新版本将很快发布，即使没有这样做，警告也不是世界末日。