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

欢迎！请查看关于页面以获取有关此工作方式的更多信息。

提出问题

编译后的函数toString()中状态函数的原始全名

0票
在错误 由

目前函数实例在 toString() 中以混入的Java名称打印

`
(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。超过1年的等待时间并不是不寻常的，尤其是对于增强功能。

0票
由

评论者：hlewisship

感谢您的信息；不想显得挑剔，但对想要改善事物的人来说，“大沉默”令人却步。

我将更新我的补丁，并希望能看到1.8的一些动作。

0票
由

由：alexmiller 发表评论

目前有 ~400 个关于 Clojure 的开放工单。作为一个打印增强功能，这通常被认为是低于缺陷的优先级。此外，该提案更改了编译器、字节码生成代码，并添加了到生成对象的字段，这些影响未评估且可能很广。这些因素结合意味着我们可能需要一段时间才能将其纳入考虑。

您可以做一些帮助的事情
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

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社区维护
...