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

欢迎！请参阅关于页面了解有关此功能的更多信息。

提出问题

编译函数的toString()中未处理的状态函数的完整名称

0投票
在 错误 由

当前函数实例在打印toString()时使用处理过的Java名称

`
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

Howard，很抱歉我没有更多有用的评论关于你在补丁中做的更改。目前我只有一两个关于其格式的小评论。补丁的首选格式是使用此维基页面上显示的说明创建的： 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。对于增强功能来说，超过一年的等待时间并不罕见。

0投票
由

评论者：hlewisship

感谢提供信息；不想表现得牢骚满腹，但巨大的沉默对希望改善事物的人来说令人却步。

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

0投票
由

评论者：alexmiller

关于Clojure的公开问题有约400个。作为打印增强，这通常被认为比缺陷的优先级低。此外，该提案改变了编译器、字节码生成代码，并为生成的对象增加了字段，这些都有未评估的潜在广泛影响。这些因素意味着我们可能需要一段时间才能着手处理这些问题。

您可以协助的事项
1) 简化描述。来到这个工作项（审核人员最终是Rich）的人希望以最少的努力了解最多。如果您还没有看过，我们在这方面有一些指南，请参阅http://dev.clojure.org/display/community/Creating Tickets。对于增强功能，最好提供（一到两句话的）对问题的简要描述和在repl中可以运行的一个示例。然后是（尽可能简短的）提案。示例：CLJ-1529, CLJ-1325, CLJ-1378。对于这样的增强，看到用户可以看到的前后版本通常是审核人员最快理解收益的方式。

2) 预测和排除障碍。如我上面提到的，您正在改变每个函数对象的大小。这会影响大小和构造时间吗？提供数据和/或测试平台可以为审核人员节省这项工作。最好将详细信息放在附件或注释中，并在描述中引用它，如果它很冗长。

3) 让别人审核（参见http://dev.clojure.org/display/community/Screening Tickets ）——虽然审核人员（通常是本人）的工作需要重新做，但在早期有更多的意见有助于。在#clojure上询问其他人查看、尝试等。如果有开放问题，将这些内容放在描述中可以有助于指导我的工作。

0投票
由

评论者：hlewisship

Alex，感谢建议。我会跟进。其中一些数据已经存在，但我会让它更加突出。

我知道我对Tapestry问题列表上的问题数量（包括增强和小的改进）感到不知所措，所以我理解问题空间。

0投票
由

评论者：[email protected]

您也可以在 AFn.java 等类似对象上实现 toString() 方法。

`
public String toString() {

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

}
`

0投票
由

评论者：alexmiller

标记+去标记是一种有损操作。请将去标记视为“尽力而为”，而非完全依赖的操作。

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