^:export 在defrecord上不受支持

Question

^:export似乎对defrecord没有影响——我只看到Closure发出了原始的def和defn符号。

我想，deftype、defprotocol等也应该是合理的目标。

无论如何，明确说明哪些功能可以支持，哪些当前不支持（advanced-compilation.adoc），这样用户就不会毫无目的地尝试各种方法。

Answer 1

评论由：mfikes发表

可以导出协议方法。建议网站更改：https://github.com/clojure/clojurescript-site/pull/148

Answer 2

_评论由：mfikes发表_

{{^:export}}仅在Vars上工作。

协议方法都是Vars，因此上述网站更改将有助于阐明如何导出它们。

考虑剩下的Vars将是为{{defrecord}}和{{deftype}}合成的map和位置工厂函数以及构造函数。

或许可以接受一种更改，使得{{(defrecord ^:export Foo [])}}将导出{{map->Foo}}、{{->Foo}}和{{Foo}}。同样，{{(deftype ^:export Bar [])}}将导出{{->Bar}}和{{Bar}}。

Answer 3

评论由：mfikes发表

解决方案：使用{{goog/exportSymbol}}

`
(ns my-ns.core)

(defrecord Foo [])
(goog/exportSymbol "my_ns.core.mapGT_Foo" my_ns.core.mapGT_Foo)
(goog/exportSymbol "my_ns.core.GT_Foo" my_ns.core.GT_Foo)
`

Answer 4

评论者：vemv

嗨，Mike，

非常感谢您对这个问题的澄清和处理！非常感激。

??^:export 仅在 Vars 上工作（且仅限 Vars）？？

我认为将这个知识点包含在文档中是一个很好的主意。为什么不将整个故事放在一个地方讲述呢？

我打开这个问题的关键担忧是记录/调试。

假设一个应用程序有一系列 singleton defrecord 实例，作为 '组件' 系统的一部分（Sierra 风格）。

然后，对于记录，我可能会尝试 {{(js/console.log (type the-instance))}}，这样我就可以识别例如一个有错误的组件。

但是没有语言支持，在没有很多样板代码或可能是一个 Hacky 宏的情况下，无法使用（或类似的）功能。

是否可能让 {{(type some-instance-of-a-defrecord-or-deftype)}} 在高级编译中打印原始名称？

Answer 5

_评论由：mfikes发表_

嗨，Victor，

感谢您对票据意图的澄清。{{\^:export}} 不是用于调试，而是为了使未重命名的符号对 JavaScript 可用。事实上，它不会改变已重命名和优化过的 JavaScript，而是简单地提供额外的未重命名的别名，它们指向优化过的/已重命名的代码。（因此，通常，调试处理的是重命名/优化过的代码，尽管旁边有未重命名的 {{^:exports}}。）

幸运的是，{{:pseudo-names}} 存在于帮助调试优化过的代码：https://script.clojure.org/reference/compiler-options#pseudo-names

对于您涉及记录实例类型的例子，如果 {{:pseudo-names}} 已启用，您将得到 {{[Function: $my_ns$core$Foo$$]}} 替代 {{[Function: ze]}}（在 Node.js 下）。

我已经对网站提出了修订： https://github.com/clojure/clojurescript-site/pull/150

如果 {{:pseudo-names}} 满足这个票据的需求，也许这个票据可以关闭。

Answer 6

参考： https://clojure.atlassian.net/browse/CLJS-2406（由 alex+import 报告）