长话短说,我正在编写一个包含选项参数的方法,如果键的值 :if 评估为真,该方法将执行某些操作。当我使用新语法在 IRB 中尝试哈希时,我在 IRB 中遇到语法错误,提示保持打开状态:
1.9.3p374 :010 > {if: true}
1.9.3p374 :011?>
使用旧语法,效果很好:
1.9.3p374 :011 > {:if => true}
=> {:if=>true}
开始语句的所有关键字都表现出相同的行为。例如。 def
, do
, module
, case
出现在中间和class
中的其他保留字可以正常工作:else
、end
我的问题是:这是预期的行为、错误还是限制?
最佳答案
以任何语言可靠且明确地解析事物都是一项挑战。当您开始使用保留字时尤其如此。而 irb
必须超越这一点,并在解析器之上提供一个交互模型,这更难。我个人认为,无论是作为语言的用户还是作为维护者,担心这样的情况都没有太大的值(value)。在我看来,最好简单地弄清楚什么是有效的,并尽可能避免陷入这些情况。
您可以在 irb
之外的普通 Ruby 中看到一些类似的行为。例如:
puts({if: true}) # no problem, behaves as expected in Ruby 1.9.3.
puts {if: true} # raises a syntax error in Ruby 1.9.3
要回答你的问题,它是“预期的行为、错误还是限制”,我会说你应该忽略 irb
并将它与普通的 Ruby 进行比较,如果你这样做,它工作良好。这意味着它必须是一个 irb
错误。
但是否有可能或值得解决? @coreyward 在他的评论中提出了一个很好的观点,即 irb
在大多数情况下遇到 if
时必须延迟执行。您必须进一步观察才能确定,但您可能无法像这样明确地解释所有情况。
我的建议:如果可以的话,完全避免这种结构,如果可以的话,不要对标签使用保留字!
这是一个您可以使用纯 Ruby(例如 MRI)运行的文件。您应该在输出中看到 {:if=>true}
以确认它有效。
{if: true}
foo = {if: true}
# if MRI is working, should be able to execute this file without trouble.
p foo
关于ruby - IRB - Ruby 1.9.x 哈希语法 : {if: true} is not equal to {:if => true},我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14966696/