2

Ruby コアでは、"foo"f凍結された文字列の新しいリテラル表記が Ruby 2.1 で提案されましたが、現在、そのような構文で記述されたコードは Ruby 2.0 で解析できないことが懸念されています。なぜそれが問題なのですか？Ruby は下位互換性だけを保とうとしていたのではありませんか? つまり、Ruby 2.0 で書かれたコードが Ruby 2.1 インタープリターで解析できれば、それで十分ではないでしょうか? Ruby 2.1 で書かれたコードが Ruby 2.0 インタープリターで解析可能でなければならないのはなぜですか?

4

2 に答える 2

1

それはとても良い質問です。私はしばらくコア ML を追跡してきましたが、ここでの主な懸念は、新しい凍結されたリテラル構文が機能の変更だけでなく、構文の変更であることだと思います。

答えを少し拡大させてください。まず、マイナー バージョンの変更について話していることを思い出してください。これは、以前のコードとの互換性を損なうことは想定されていません。実際、これはまったく起こらないと主張するかもしれません。Ruby 2.0 コードは Ruby 2.1 でも問題なく動作しますが、その逆ではありません。

また、新しいバージョンには以前のバージョンでは利用できなかった機能が含まれる可能性があることを暗示しているとも述べました。しかし、ここからがまさに懸念の始まりだと思います。

新しい構文では、機能の変更だけでなく、構文の変更も導入されています。これは、Ruby 2.0 パーサーに Ruby 2.1 コードをフィードしようとすると、失敗する可能性があることを意味します。これは、すでにわかっているすべての理由 (互換性、移行、メンテナンスなど) から、良い考えではないかもしれません。

これは、Ruby 2.0 で使用できない新しいメソッドを Ruby 2.1 で作成する場合とはまったく異なります。この場合、2.1 が 2.0 よりも多くの機能を持つことは事実ですが、以前のインタープリターに同じコード ベースをフィードしても、文句はありません。言語の構文を変更したのではなく、コア ライブラリを強化しただけです。この場合、2.0 のコードを 2.1 に似たものにするのは非常に簡単です。不足しているメソッドを実装するだけです。

パーサーを再実装する必要があるため、これは構文の変更では不可能です。

この時点での Ruby の変更を見ると、マイナー バージョン間で導入された構文の変更が非常に少ないことがわかります。

ずんぐりしたラムダ、キーワード引数、新しいハッシュ表記などの変更は、すべて大きなバンプで導入されました。

一般的に言えば、構文レベルの変更は、機能レベルの変更と比較して、より多くのメンテナンスの問題を引き起こす可能性があります。これは、新しい凍結されたリテラル構文の背後にある理由と.freeze、新しい構文の代わりに使用することになった理由についての私の解釈です。freeze以前の Ruby バージョンには既に存在しますが、完全に新しいメソッドが付属する場合でも、メソッドは解析時に評価されず、簡単にバックポートできます。

于 2013-12-25T17:18:28.807 に答える