编译函数中状态函数的非混淆全名

Question

当前函数实例使用混淆的Java名字打印toString()。

`
(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"]

`

出于调试目的，有一个描述Clojure式fn名称的toString()将是非常有用的。

方法：在函数实例中存储原始名称并在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

Answer 1

评论者：hlewisship

包含更改和更新的测试。我没有任何有关这些更改是否会影响编译器性能或生成的代码大小的详细信息。

Answer 2

评论者：jafingerhut

霍华德，很抱歉我没有更多关于你补丁中变更的有用评论。现在我只对它的格式有几点小意见。补丁的首选格式是按照本wiki页面所示说明创建的：[http://dev.clojure.org/display/community/Developing+Patches](http://dev.clojure.org/display/community/Developing Patches)

另外，你的补丁中似乎有多个部分只是在行间距上做了更改。在提议的补丁中最好省略这些更改。

Answer 3

评论者：hlewisship

是的，我在之后注意到空白符改变；我可能在哪里触发了格式化，尽管我尽力避免。我将在不久后提交一个新的补丁。

Answer 4

评论者：hlewisship

干净的补丁

Answer 5

评论者：hlewisship

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

Answer 6

评论者：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"))

`

如果有任何迹象表明我的补丁会被采用，我会乐意向更新。自上次更新以来已经超过一年了。

Answer 7

评论者：jafingerhut

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

顺便问一下，不，我知道的不一定是有关注意力的工单。我知道这个工单获得了相当多的投票，并且根据投票是排名前茅的增强建议 - 在报告中的“增强”部分查看，或搜索1330: http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

要进入Clojure 1.7的特性已经基本确定，还有很多其他的修复和增强被推迟到1.8。超过一年的等待时间对于增强来说并不罕见。

Answer 8

评论者：hlewisship

感谢提供信息；不想表现得过于抱怨，但对一个想帮忙改进事物的人来说， 슈퍼사이드 액션은 말하고나서도 괜찮다.

我将更新我的补丁，希望看到1.8版本的一些动态。

Answer 9

评论者：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上询问其他人看看、尝试它等。如果有未解决的问题，将它们留在描述中有助于指导我的工作。

Answer 10

评论者：hlewisship

Alex，感谢你的建议。我会跟进的。其中一些数据已经存在，但我可以使其更加突出。

我了解到Tapestry问题列表上有大量问题（包括增强和小的改进），所以我理解问题空间。

Answer 11

评论者：[email protected]

你可以改在类似AFn.java的某物上实现toString()。

`
public String toString() {

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

}
`

Answer 12

评论者：alexmiller

加蒙版和去蒙版的操作是不可逆的。将去蒙版视为“尽力而为”，而不是可以依赖的操作。

Answer 13

参考资料：https://clojure.atlassian.net/browse/CLJ-1278 （由 hlewisship 报告）