| title | date | author | tags | keywords | categories | reward | reward_title | reward_wechat | reward_alipay | source_url |
|---|---|---|---|---|---|---|---|---|---|---|
[译]Modifiers vs Annotations |
2015-08-11 10:47:00 -0700 |
Andrey Breslav |
官方动态 |
false |
Have a nice Kotlin! |
这是另一个单挑和反馈的呼吁。我们一直在讨论有关Kotlin注释语法的选项，推出实验，收集反馈。当我们现在完成语言的定义时，我们以前推迟的许多痛点就是浮出水面。我们必须作出决定，有时以防御的方式。在这篇文章中，我将概述我们所选择的选项以及我们所提供的决策。
Kotlin（以及许多其他语言）有两种元数据</ em>：
- 修饰语（如公开，开放或抽象），内置于语言中
- 在库中定义的注释（如@Test或@Inject）也可以有参数。
与许多语言不同，在Kotlin 中，大多数修饰符都不是正确的关键字</ strong>。只有在适用的情况下才具有特殊意义，即声明前。编译器不会介意，如果你调用你的变量或类 public </ code>：
{% raw %}
{% endraw %}
val public = "PUBLIC!"
println(public)
{% raw %}
{% endraw %}
这种技术被称为“软关键字”或“上下文关键字”。 </ span>
当Kotlin被设想时，我个人对统一元数据</ em>的想法很着迷：我认为我们应该达到一个修饰符和注释之间没有区别的地方。所有的元数据应该被明确声明，并被平等对待。它是统一，可扩展，否则伟大！语言设计师和用户都可以定义注释并扩展其语言。在我理想的世界里，没有修饰符，只有注释，即 public </ code>将是一个注释，以及 inline </ code>， abstract </ code>，枚举</ code>等
那么事实证明，在语言实现的早期阶段，技术上引入修改器（而不是注释）容易得多，所以我们这样做是一个临时措施。
这就是为什么Kotlin允许没有 @ </ code>的注释：我希望他们看起来像修饰符，以便稍后可以将修饰符转换为注释。许多您可能认为的修改器实际上是注释： data </ code>和 inline </ code>是最受欢迎的。
现在，我不得不承认，统一元数据的梦想虽然并不完全不可能实现，但实际上是不切实际的。
修饰符具有在解析阶段之后可用的特有属性。这对于一些关键性的任务非常重要（例如在IDE中），因为它们有时候依赖于知道什么是公共的，哪些不在上下文中，没有什么是准备好但是已解析的文本。
所以，修饰符必须保留</ strong>。
现在，最初的想法是挑战的：如果我们不统一修饰符和注释，是否有一点保持他们的语法相似？
一方面，看起来很酷</ strong>，我们可以在注释之前省略“@”。人们可以认为它减少了代码中的“噪音”数量。
另一方面，有一堆问题，其中没有一个是至关重要的，但是它们很烦人：
首先，它不正交</ strong>：我们可以在注释前使用“@”。这是大多数时候的惯例问题。但是有时我们必须使用“@”：本地类和函数是最臭名昭着的例子。
然后，会使错误恢复复杂化</ strong>：代码正确无误，但是当您在IDE中键入时，解析器必须能够从错误中恢复并识别不完整的代码结构代码</ em>。随机标识符是可解析的，因为注释使这一点相当复杂。
此外，使命名约定变得复杂</ strong>：我们用来命名小写中第一个字母的注释，例如 @inline </ code>或 @platformStatic </ code>。许多人在这种情况下发现骆驼案多字的名字像后者一个丑陋。因此，有一些建议只能将小写字母用于单字注释（看起来像修饰符）。还有Java注释（其中许多被频繁使用）仍以大写第一个字母命名。总而言之，这是一团糟。一个小的，但还是一团糟。
而且更具技术性，但仍然是现实的关切：使语言进化复杂化</ strong>。我们无法在下一个版本的Kotlin中添加一个新的修饰符“foo”，而不会破坏某人的代码：如果某个库具有注释 foo </ code>，则会发生冲突，编译器可以做的最好的报错。
所以我们认为这个成本太小了。
顺便提一句，我们认为，在需要时允许修饰符具有参数是有意义的。它有助于语言演进（我们可以在以后添加可选参数到现有的修饰符），似乎没有引入任何问题。例如， annotation </ code>是一个修饰符（在解析名字之前需要知道注解类），但它有参数：
{% raw %}
{% endraw %}
annotation(repeatable = true) class MyRepeatableAnnotation
{% raw %}
{% endraw %}
我们将要求所有注释以“@”为前缀。
顺便提一下，一些注释将会变成修饰符：例如， data </ code>和 inline </ code>。
欢迎您的反馈</ strong>：我们想知道我们是否在这里遗漏了您的意见。
特别感谢作者和贡献者 这个论坛的主题 。