为什么用 Ruby 2.1 编写的代码必须能够被 Ruby 2.0 解释器解析？

Question

在 Ruby Core 中，已经为 Ruby 2.1 提出了一种用于冻结字符串的新文字符号 "foo"f，但 now 人们担心以这种语法编写的代码无法被 Ruby 2.0 解析。为什么这是个问题？ Ruby 不是只尝试向后兼容吗？也就是说，如果用 Ruby 2.0 编写的代码可以被 Ruby 2.1 解释器解析，那还不够吗？为什么用 Ruby 2.1 编写的代码必须能够被 Ruby 2.0 解释器解析？

Answer 1

这是一个很好的问题。我关注核心 ML 有一段时间了，我认为这里的主要问题是新的冻结文字语法是语法变化，而不仅仅是功能变化。

让我稍微扩展一下答案。首先，让我们记住，我们谈论的是次要版本更改，它不应该破坏与以前代码的兼容性。事实上，您可能会争辩说，事实上，这根本不会发生。 Ruby 2.0 代码在 Ruby 2.1 中可以正常工作，但不能相反。

您还提到暗示新版本可能包含以前版本中不可用的功能。但我相信这正是问题的根源所在。

新语法不仅引入了功能更改，还引入了语法更改。这意味着，如果您尝试向 Ruby 2.0 解析器提供 Ruby 2.1 代码，它可能会失败。由于我们已经知道的所有原因（兼容性、迁移、维护等），这可能不是一个好主意。

这与在 Ruby 2.1 中创建一个 Ruby 2.0 不可用的新方法时完全不同。在这种情况下，确实 2.1 会比 2.0 拥有更多的功能，但是如果您使用相同的代码库提供以前的解释器，它就不会抱怨。你没有改变语言语法，你只是丰富了核心库。而且，在这种情况下，很容易让您的 2.0 代码更类似于 2.1：只需实现缺少的方法即可。

这在语法更改时是不可能的，因为您需要重新实现解析器。

如果您查看您在这一点下的 Ruby 更改，您会发现在次要版本之间引入了非常少的语法更改。

像 stubby lambda、关键字参数、新的哈希表示法这样的变化，它们都是在引入时带来了重大影响。

一般来说，语法级别的更改与功能级别的更改相比可能会导致更多的维护问题。这是我对新冻结文字语法背后的原因以及它们最终使用.freeze instead of the new syntax 的原因的解释。 freeze 已经存在于之前的 Ruby 版本中，但即使它们带有全新的方法，方法也不会在解析时进行评估，并且可以轻松地向后移植。

Answer 2

我想到的答案是：

• 更轻松地从 ruby​​ 2.0 迁移到 2.1
• ruby 版本之间共享代码
• 人们似乎觉得 f 后缀丑陋/令人困惑

迁移

当两个 ruby​​ 版本都可以解析语法时，从 2.0 迁移到 2.1 就少了一项任务。无需任何更改，现有代码可能会受益于更好的冻结字符串处理。

ruby 版本之间的共享代码

使用类似的语法，您可以编写与多个 ruby​​ 版本（2.0 和 2.1）一起使用的 ruby​​ 代码（尤其是库）。这为库开发人员提供了更多的受众（并且为不同的 ruby​​ 版本维护的版本更少）。然而，图书馆用户可以更轻松地从 ruby​​ 2.0 迁移到 2.1。 ruby 2.1 版本仍然可以从更好的冻结字符串处理中受益。

个人口味

通过阅读 ruby​​ 错误跟踪器，我发现有些人似乎觉得新语法丑陋/令人困惑。以下是一些示例：

• "[not using the f-suffix] looks like Ruby"
• "The [f-suffix] notation is ugly."
• "it is confusing about the character 'f'. For example, it remind 'Float'"
• "I personally dislike prefix/suffix forms, they feel like u'str' in python"
• "it looks very strange"（好吧，这不是来自tracker）

还有其他人喜欢新语法。嗯，这是主观的，但我们想知道为什么人们会抱怨，所以这是一个重点:)