_评论由：_
请基于以下原因重新考虑这个“修复”
- 为了一致性，需要修复(keyword "foo/bar/baz")
- 它会破坏我的代码的用户
-
http://docs.caudate.me/adi/adi-guide.html -
http://docs.caudate.me/adi/adi-walkthrough.html#schoolyard
请在此主题下查看讨论
dm3 [下午5:04]
为什么 `(read-string "a/b/c")` 可以正常运行，而 `(clojure.tools.reader/read-string "a/b/c")` 会因为“无效的标记”失败呢？
hiredman [5:04 PM]
有一个关于修复 `read-string` 的票
dm3 [5:05 PM]
所以正确的做法是让它失败吗？
hiredman [5:05 PM]
http://dev.clojure.org/jira/browse/CLJ-1530
dm3 [5:06 PM]
谢谢，看起来这是一个破坏性的变更 :simple_smile
hiredman [5:07 PM]
文档已经在一段时间前阻止了诸如 a/b/c 这样的符号，而这些非规定符号的读取行为似乎在某处发生了变化
lucas [5:09 PM]
加入了 #clojure
zcaudate [5:16 PM]
@hiredman：真的。我真的很烦这个问题，因为我一直在使用 `:a/b/c` 关键字… 甚至写了一个专门的库来处理这个问题
http://docs.caudate.me/hara/hara-string.html#api---path (修订)
[5:16]
现在他们要移除它了
[5:18]
我认为应该首先移除 `::foo/baz` 这样的关键字
[5:20]
```user=> (require '[clojure.walk :as walk])
nil
user=> ::walk/hello
:clojure.walk/hello
```
[5:20]
这会导致很多问题
[5:20]
特别是在分析器中
[5:22]
https://github.com/jonase/kibit/issues/14
GitHub
Kibit 在处理名称空间限定关键字时出错 · Issue #14 · jonase/kibit · GitHub
如果代码中包含具有别名名称空间限定的关键字，Kibit 会因为无效标记异常而出错。下面的代码展示了这个问题 - ;;; foo.clj (ns foo) ;;; bar.clj (n...
[5:25]
@dm3 如果真的有问题，你可以修复它
[5:25]
https://github.com/helpshift/hydrox/blob/master/lein/src/leiningen/hydrox/setup.clj
GitHub
helpshift/hydrox
hydrox - 深入挖掘你的代码
dm3 [5:31 PM]
是的，不幸的是，还得修复 cljs.tools.reader：confused
[5:31]
我想我只能暂时解决方案
bronsa [5:36 PM]
@zcaudate：`::foo/bar` 风格的关键字是按设计加入的，不会去除，`:foo/bar/baz` 按规范始终是无效的，并且是不确定的行为 (修订)
[5:37]
@dm3：改变不确定的行为是破坏性的变更吗？ :simple_smile
dm3 [5:37 PM]
破坏性的意思是破坏人们代码的变更 :simple_smile
[5:37]
例如 zcaudate
bronsa [5:38 PM]
如果代码使用无效的 clojure，那么它已经损坏了。这只是偶然有效
dm3 [5:39 PM]
我从实用主义的角度来看。从理论上讲，你是对的 :simple_smile
[5:40]
我不会做出评判
bronsa [5:40 PM]
实用主义地讲，`:foo/bar/baz` 是一个即将发生的错误。`(namespace :foo/bar/baz)` 会返回什么？
dm3 [5:40 PM]
无论是目前实现的意义上返回什么
[5:41]
我是指，它某种程度上是由实现定义的
sveri [5:41 PM]
@dm3 @bronsa 我认为你们理论上都是对的。一旦足够多的人适应了这种破损代码，它就会变成类似约定俗成的法律，双方都接受很长时间。
bronsa [5:42 PM]
那么，关于 `(keyword "foo/bar" "baz")` 和 `(keyword "foo" "bar/baz")` 上的 `namespace` 呢？
dm3 [5:43 PM]
我同意，目前的实现语义是混乱的
[5:43]
但是我的观点是，这仍然是一个破坏性的变更
[5:43]
并不是说这是一个“不好的”变更
[5:43]
那是一个判断
bronsa [5:43 PM]
@sveri： 我会同意你的，只要我们接受的未定义行为不会导致无法修复的语义。
[5:44]
这就是为什么例如，使以数字开头符号非法的修复被撤销的原因
[5:45]
它破坏了现有代码，但它没有导致奇怪的语义，因此被撤销了。与 `:foo/bar/baz` 不同
[5:45]
@dm3：你可以说修复任何错误都是破坏性的变更 - 人们可能会依赖这个错误。
dm3 [5:46 PM]
是的，我认为重要的是错误的程度以及有多少人依赖它
bronsa [下午5:46]
如果文档明确说“您可以在符号中使用一个`/`”，那么如果您使用了多个，那么您编写的是无效的Clojure代码，并且预期它可能会崩溃（已编辑）
dm3 [下午5:47]
我在过去3年的Clojure使用过程中，甚至没有考虑过符号中的多个斜杠（也没有注意到文档）
[5:47]
今天我最初的看法是这是允许的
[5:47]
并且命名空间将是第一个斜杠之前的第一部分（已编辑）
bronsa [下午5:51]
但是，这并不合理。在Clojure中，`/`代表`命名空间分隔符`。无论`FOO`和`BAR`是什么，如果我看到`FOO/BAR`，我都知道`FOO`是命名空间，`BAR`是名称。如果您想像@zcaudate的库中使用关键字来表示路径，您应该在关键字中使用不同的分隔符，这样在Clojure中没有特殊意义，例如`.`（即`:foo/bar/baz` -> `:foo.bar.baz`或`:foo/bar.baz`）（已编辑）
dm3 [下午5:51]
我不想争论术语。只是分享一种观点
bronsa [下午5:52]
我的观点是，只有在它们暗示的语义清晰且明确的情况下，才应考虑实用主义观点（特别是当它们与当前文档相矛盾时）
sveri [下午5:53]
@bronsa：很好的解释，谢谢：简单微笑
dm3 [下午5:53]
是的：简单微笑
[5:54]
我同意这一点，因为最终你必须做决定
zcaudate [晚上9:07]
@bronsa：文字沟通的方式往往把事情看得比实际情况严重
[9:08]
说实话... 我从1.6版本开始就知道这种情况会发生，因为edn读取器开始使我的代码崩溃
[9:09]
这可能更多的是我的错，因为我没有早点沟通这个，但哦，毕竟...我们都必须随波逐流
bronsa [晚上9:09]
@zcaudate：没关系，我只是在用你的库作为例子，因为你提到了
zcaudate [晚上9:10]
话虽如此，你可以想象我的失望，因为我已经根据关键字`:foo/bar/baz`功能（现在是错误）设计了整个查询语义（已编辑）
[9:11]
http://docs.caudate.me/adi/adi-walkthrough.html#querying
[9:11]
您注意到了，我没有在我的文档中使用`(adi/select ds {:student/classes/teacher/name "Mr. Blair"})`
[9:12]
因为我开始的测试已经崩溃（已编辑）
jstew [晚上9:12]
@zcaudate：你发布了这么多高质量的产品，我怀疑你是否从不睡觉！
1
bronsa [晚上9:12]
@zcaudate：幸运的是，修复应该是容易的：简单微笑：只需将`/`替换为`.`即可
zcaudate [晚上9:12]
不！
[9:13]
问题是... datomic有`account.type/user`之类的东
[9:13]
所以我必须像cljs那样做 `account.type$user`
bronsa [晚上9:13]
（顺便说一句，这是高质量的文档，干得好）
zcaudate [晚上9:14]
@bronsa：哈哈谢谢... 所以也许你可以把修复推进到1.10
[9:14]
这样的话我可以再得到几个月的时间
[9:15]
因为不是什么大问题...但是我以为`/`调用路径的结构和映射的嵌套之间有某种对应关系
[9:16]
因此与`{:student {:classes {:teacher {:name '(?fulltext "Blair")}}`等价
[9:17]
和`{:student/classes/teacher/name "Mr. Blair"}`
[9:17]
在我看来这更漂亮
bronsa [晚上9:17]
@zcaudate: 对不起如果这不够清楚，但事实上我无法控制什么能进到clojure中，或者何时能进到，我只是一个贡献者：简单微笑，所以 clojure/core 团队可能会做出不同的决定，并实际上拒绝这个工单（如果真的是这样，我肯定会非常失望的！）。如果发生这种情况，我会显然修改 `tools.reader` 以允许它们这样做（修改过）。
zcaudate [21:18]
@bronsa: 该死的。
[9:19]
嗯…也许你可以突出这个事实
[9:19]
另外，如果做出了修复，还需要对 `(keyword "foo/bar/baz")` 做出修复（修改过）。
bronsa [21:20]
我认为这永远都不会做。曾经无数次有人请求/讨论过对 `keyword`/`symbol` 等进行输入验证，但由于性能原因而被反复拒绝。
zcaudate [21:20]
所以这是一个一致性的问题。
bronsa [21:20]
（虽然我不完全同意这个决定，但看样子 Rich 在这个问题上不会改变主意）
[9:21]
@zcaudate: 符号/关键字的运行时可能是什么，以及在有效读取时可能是什么，这两者之间有区别。
zcaudate [21:21]
另外，这意味着我可以设置一个读取宏 #k foo/bar/baz，并得到相同的效果
[9:22]
虽然它看起来很愚蠢，但我觉得它应该会工作
bronsa [21:23]
但关于如何处理 `namespace` 和 `name` 的歧义仍然存在，所以我不知道
[9:23]
@zcaudate: 无论如何，如果
http://dev.clojure.org/jira/browse/CLJ-1530 被接受，那么 `:foo/bar/baz` 和 `foo/bar/baz` 都将不再有效
[9:24]
@zcaudate: 顺便说一下，如果你强烈反对这个，我建议你在那里评论你的问题
新的消息
[9:25]
我 **怀疑** 他们的回复将是“你应该使用一个在 clojure 中没有特殊意义的分隔符”，但我可能完全错了（我发现核心团队并不经常同意我的观点 :)），尤其是如果你指出你的库会出现问题。（修改过）
zcaudate [21:30]
@bronsa: 谢谢提醒。我会留言并祈求 bdfl
