宏在工具支持

Comment from discussion abreslav’s comment from discussion "Kotlin Team AMA: Ask Us Anything".

传统的宏很难在工具中得到很好的支持

在Java中，我们已经有了Lombok @Data生成方法，几乎​​和宏一样。 https://projectlombok.org/features/Data

为什么宏在工具上很难支持？

Answer 1

工具可以意味着许多不同的事情，从执行宏转换的二进制代码的低级别，直到您正在实施或使用宏的IDE的高级别，这正是abreslav提到的。 由于宏可以改变它们包含的代码的含义，所以你开始遇到像决定要向用户显示哪种types的源代码这样的问题 。

假设有一个宏，它将所有的属性加上一个字符串前缀，在标识符的连接过程中自然地将原始variables大写：

someclass { prefix("longPrefix") { val a: String = "" } fun bar() { println("Look at $longPrefixA") } } 

想象一下，这个编译和工作，你很难回答设计决策，因为你是在宏转换之前显示的原始源…但是看到后面的代码不是有用的吗？ 此外，部分源代码依赖于正在运行的宏，这意味着IDE必须在键入时实际编译和运行代码，以validation对$longPrefixA的引用是否有效。 从某种意义上说，如果您是首先编写宏，则需要编译器/ IDE的编译时调试器，就像您有运行时的常用调试器一样。

当你想到控制流宏，以及以非显而易见的方式修改编译抽象语法树的时候，还有更多的麻烦，这也是宏得到隐藏程序的坏名声的原因之一（虽然我认为主要来自我们的C文本预处理器有偏见的历史）。 即使你看到其他编程语言，并且内置了宏支持，他们的工具也往往是平淡无奇的，从而延续了这个模式。

Answer 2

当IDE做的正确时，宏并不难支持。

关键是在IDE中使用相同的编译器来实现语义特征。