ステートメントがruby 1.9でスコープを導入しないのはなぜですか？

ステートメントがRuby 1.9でスコープを導入しない場合、Ruby 1.8からのこの変更の背後にある根拠は何ですか？

これがRuby 1.9で行われた2つの理由は次のスライドにありますが、発表者のダイアログなしでは明らかではないかもしれません。no scope ifステートメントを使用して実行できる2つのことは、ifステートメントの外部からアクセスできるソースコード内のことを定義することです。

最初の例：メソッドの置き換え

class Employee
  if String.method_defined?(:encode)
    def name
      ...
    end
  else
    def name
      ...
    end
  end
end

この例では、メソッドに2つの異なる定義がありnameます。場合に使用される一つString.encodeの方法が存在し、エンコード方法が存在しない場合に使用される一方（下位実装）。基本的に、これにより、ライブラリがサポートしていれば、正しくエンコードされた文字列を使用できます。

2番目の例：実装の置き換え

if String.method_defined?(:encode)
  module Builder
    ...
  end
else
  class String
    ...
  end
end

この例では、ライブラリ機能が存在するかどうかに応じて、完全に異なるクラス/モジュールを提供しています。これにより、新しいライブラリ機能を使用する完全に異なるアルゴリズムを使用しながら、存在しない場合は十分に効率の悪い、または完全なアルゴリズムにフォールバックできます。

すべての重要な理由

これで何が買えるの？ifステートメントが新しいスコープを導入した場合、新しいメソッドまたはクラスは存在し、ifステートメントの範囲内でのみ使用されます。この制約により、将来1.9から移行する際にRuby 2.0の変更が必要なライブラリをサポートすることは非常に困難になります。

リンク先のプレゼンテーションで提供されている両方の例で、理由は、Rubyの複数のバージョンをサポートしながら、ライブラリの1つのコードベースを維持することです。Ruby 1.8とRuby 1.9の間の移行の苦痛から生まれたと思います。Rubyチームは着実に2.0に向かって進んでいるため、互換性のない変更がある場合でも、ユーザーをサポートすることができます。1.9.1と1.9.2の間にいくつかあったと思います。将来的にはもっとあります。

私は専門家ではありませんが、RubyのFAQをご覧になる場合は、http：//arc.apotheon.org/ruby/faq/rubyfaq-2.phpをご覧 ください。

2.3節「ローカル変数はいつアクセス可能になるのですか？」現在の動作を示します。

スコーピングの問題を回避するために、現在実行する必要があるわずかに「ハック」なことの1つは次のとおりです。

このようなローカル変数の動作に悩まされないように、ローカル変数にアクセスする前に、a = nilのような割り当てステートメントを置くことをお勧めします。

私は 1.9でこれを行う必要がなくなると信じています。これは新しい振る舞いの原動力の1つかもしれません。