在2024年Clojure状态调查！分享您的想法。

欢迎！请参阅关于页面以了解更多关于这是如何工作的信息。

提问

编译函数toString()中状态功能的未篡改全名

0票
在 错误 由

目前函数实例以经过篡改的Java名称打印toString()方法

`
user=> (ns proj.util-fns)
nil
proj.util-fns=> (defn a->b [a] (inc a))

proj.util-fns/a->b

proj.util-fns=> a->b

object[proj.util_fns$a__GT_b 0x141ba1f1 "proj.util_fns$a__GT_b@141ba1f1"]

`

出于调试目的，如果函数toString()能描述面向Clojure的fn名称将很有用。

方法：在函数实例中存储原始名称，并在toString()中使用它，而不是返回类名。

`
proj.util-fns=> a->b

object[proj.util_fns$a__GT_b 0x47d1a507 "proj.util-fns/a->b(NO_SOURCE_FILE:2)"]

`

权衡：增加函数实例的大小以容纳函数名称。

补丁：CLJ-1278-2.patch

13 个回答

0票
由

评论：hlewisship

包含更改和更新的测试。我没有关于这次更改是否对编译器性能或生成的代码大小有显著或可测量的影响的具体细节。

0票
由

评论：jafingerhut

霍华德，很抱歉我没有对你补丁中的修改提出更有用的评论。 目前我只有关于其形式的几个小意见。 修补文件的推荐格式是使用此维基页面上的说明创建的： http://dev.clojure.org/display/community/Developing Patches

此外，你的补丁中似乎有一些部分只是修改了行的空白部分。最好将这些修改从建议的补丁中删除。

0票
由

评论：hlewisship

是的，我没有注意到空白处的变化，直到后来。我可能在不情愿的情况下无意中触发了格式化。我很快将准备一个新的补丁。

0票
由

评论：hlewisship

干净的补丁

0票
由

评论：hlewisship

顺便说一句，已经过去一年了。正确的文件是 CLJ-1278-2.patch。

0票
由

评论：hlewisship

...嗯，最近有些东西变了。

`

 [java] FAIL in (fn-toString) (fn.clj:83)
 [java] nested functions
 [java] expected: (= (simple-name (.toString (factory-function))) (str "clojure.test-clojure.fn/" "factory-function/fn"))
 [java]   actual: (not (= "clojure.test-clojure.fn/factory-function/fn__7565" "clojure.test-clojure.fn/factory-function/fn"))
 [java]
 [java] FAIL in (fn-toString) (fn.clj:83)
 [java] nested functions
 [java] expected: (= (simple-name (.toString (named-factory-function))) (str "clojure.test-clojure.fn/" "named-factory-function/a-function-name"))
 [java]   actual: (not (= "clojure.test-clojure.fn/named-factory-function/a-function-name__7568" "clojure.test-clojure.fn/named-factory-function/a-function-name"))

`

如果任何迹象表明我的补丁会被采纳，我会乐意更新我的补丁。自从上次更新以来已经过去一年多时间。

0票
由

评论：jafingerhut

你所看到的行为变化很可能是由于对工单 CLJ-1330 的修复。

顺便问一下，不，我不是那个知道哪些工单感兴趣的。我知道这个已经得到了不少投票，并且通过投票是排在首位的增强建议之一 - 在这份报告的“增强”部分查看，或搜索 1330： http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

进入 Clojure 1.7 的功能已经相当明确，大量其他修复和增强被推迟到 1.8。超过 1 年的等待时间并不罕见，特别是对于增强功能而言。

0票
由

评论：hlewisship

感谢您提供信息；不想显得娇气，但对想要改进事物的人来说，《大沉默》让人望而却步。

我会更新我的补丁，并希望看到1.8的一些进展。

0票
由

评论者：alexmiller

Clojure有大约400个开放票证。作为一个打印增强功能，这通常被认为是低于缺陷的优先级。此外，该提案改变了编译器、字节码生成代码，并增加了生成对象中的字段，这有未评估的潜在广泛影响。这些组合意味着我们可能需要一段时间才能开始关注它。

您可以做的事情来帮助
1) 简化描述。来这个票证的人（筛查和最终Rich）希望通过最少的工作了解描述的最大意义。如果您还没有看到，我们在这方面有一些指南：http://dev.clojure.org/display/community/Creating Tickets。对于一个增强，最好有一个简短的（1-2句话）的关于问题和示例的描述，这个示例我可以在repl中运行。然后一个提案（再次提醒，尽可能简短）。示例：CLJ-1529，CLJ-1325，CLJ-1378。对于这种增强，看到（简洁的）用户将看到的之前/之后版本通常是筛查人员了解收益的最快方式。

2) 预见并消除阻碍。如上所述，您正在改变每个函数对象的大小。这种大小的变化和构建时间有何影响？提供数据和/或测试平台可以节省筛查人员的工作。最好在附件或注释中留下详细资料，并在描述中引用它（如果篇幅较长）。

3) 让其他人进行筛查（根据http://dev.clojure.org/display/community/Screening Tickets）——虽然筛查人员（通常是本人）的工作需要重新做，但尽早让更多人查看它有助于。在#clojure上询问其他人来看、尝试等。如果有开放的问题，将这些留在描述中有助于引导我的工作。

0票
由

评论：hlewisship

亚历克斯，感谢您的建议。我会跟进。一些数据已经存在，但我可以使其更突出。

我知道我在Tapestry问题列表上的问题数量很多（包括增强和微小改进），我理解问题领域。

0票
由

评论者：[email protected]

您可以在类似AFn.java的某处实现toString()。

`
public String toString() {

String name = getClass().getSimpleName();
return Compiler.demunge(name);

}
`

0票
由

评论者：alexmiller

Munge+demunge 是一种有损操作。将demunge视为“尽力而为”，而不是可以依靠的东西。

0票
由
参考： https://clojure.atlassian.net/browse/CLJ-1278（由 hlewisship 报告）
由Cognitect维护，代表Clojure社区
...