缺少 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 提供

我们必须考虑向量或其他关联数据结构，而不仅仅是映射。我也希望不要使用标志，而是保留它们以便去除多个数据。

使用类似以下的方式

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

我们将得到 {{[{}]}}，所以现有的方法确实会留下空集合。

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

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

Answer 2

评论由：alexmiller 提供

是的，但在更新案例中，我认为这些因素平衡不同。在更新中，实现更少，并且它们符合我们拟添加的内容。因此，它们创造了将现有功能替换为内核功能的潜力。

我认为常见的实用程序库实现（flatland/useful/plumbing）实际上是在满足不同的需求——仅在地图上进行更新-in、disoc和历史路径移除。所以，如果目标是要覆盖常用用法，那么我们就需要让它只在地图上运行，并移除留下的空路径。然而，我认为这与其他内核-in函数有些矛盾。我想也许有一个折衷的办法来进行路径移除，但使其适用于除了地图之外的情况——这样既能满足实用程序库所示的需求，又能像其他-in函数一样通用。如果你需要留下空的集合，你可以做你现在正在做的事情——update-in+disoc。

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中的那个进行比较，我刚刚恰好发现了它。我看到它们看起来不同，但我还没有检查是否存在任何行为差异。

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

Answer 6

_评论者：bronsa_

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

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}}


这种行为出乎意料。虽然 incubator 版本也有这个问题，但它确实会删除空映射。

我正在为这个补丁编写测试（以及可能的新 dissoc-in），但我不太清楚是否应该保留或删除空路径？我不介意哪种方式，尽管我倾向于同意 Andrew Rosa 的观点，即保留它们更为对称。

Answer 11

评论者：[email protected]

@alex，你希望保留空路径还是删除它们？两种方式都可以接受，尽管我稍微倾向于留下它们。一旦我知道你要走哪条路，我就可以为这个编写测试。

Answer 12

评论由：alexmiller 提供

两种方式各有利弊是什么？

在人们使用 dissoc-in 代理（带 dissoc 的 update-in 等）的地方，他们期望什么行为？

Answer 13

_发表评论：michalmarczyk_

如果我们只想处理嵌套在另一个地图中的地图……，我可能更愿意删除空子路径。

然而，如果我们想沿途中容纳向量，那么将该空路径保留下来可能在那种情况下会更清晰的语义。


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


相比之下，移除空路径可能似乎会导致需要通过限制移除路径的行为到地图或当子路径嵌套在向量 成为条目时抛出，两种方法似乎都不是最佳选择。

Answer 14

发表评论：michalmarczyk

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

Answer 15

评论者：bronsa

相同的论点也可能适用于包含 update 的情况。实际上，由于 update 和 dissoc-in 可以在多个实用库中找到，这应该表明人们不满意仅仅使用 update-in + dissoc。

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