Pourquoi si les instructions n'introduisent pas de portée dans ruby ​​1.9?

si les déclarations n'introduisent pas de portée dans Ruby 1.9, quelle est la justification de ce changement par rapport à ruby ​​1.8?

Deux raisons pour lesquelles cela a été fait dans Ruby 1.9 sont sur les diapositives suivantes, bien que cela ne soit pas évident sans la boîte de dialogue du présentateur. Deux choses que les ifinstructions no scope vous permettent de faire est de définir dans votre code source des éléments accessibles en dehors de l'instruction if.

Premier exemple: remplacer les méthodes

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

Dans cet exemple, il existe deux définitions différentes pour la nameméthode. Un qui sera utilisé si la String.encodeméthode existe et un (implémentation inférieure) qui sera utilisé si la méthode d'encodage n'existe pas. Essentiellement, cela vous permet d'utiliser une chaîne correctement codée si les bibliothèques la prennent en charge.

Deuxième exemple: remplacer l'implémentation

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

Dans cet exemple, nous fournissons une classe / un module complètement différent selon qu'il existe une fonctionnalité de bibliothèque. Cela vous permet d'avoir un algorithme complètement différent qui utilise une nouvelle fonctionnalité de bibliothèque tout en retombant sur un algorithme moins efficace ou complet suffisamment proche s'il n'existe pas.

Le tout important pourquoi

Alors qu'est-ce que cela vous rapporte? Si l' ifinstruction introduisait une nouvelle portée, la nouvelle méthode ou classe n'existerait et ne serait utilisée que dans les limites de l' ifinstruction. Cette contrainte rend très difficile la prise en charge d'une bibliothèque qui aura besoin de modifications pour Ruby 2.0 à mesure que nous migrerons de la version 1.9 à l'avenir.

Avec les deux exemples fournis dans la présentation à laquelle vous avez lié, le raisonnement est de conserver une base de code pour vos bibliothèques tout en prenant en charge plusieurs versions de Ruby. Je crois qu'il est né de la douleur de la transition entre Ruby 1.8 et Ruby 1.9. Comme l'équipe Ruby progresse régulièrement vers 2.0, vous pourrez toujours soutenir vos utilisateurs en cas de modifications incompatibles. Je pense qu'il y en avait entre 1.9.1 et 1.9.2. Il y en aura d'autres à l'avenir.

Je ne suis pas un expert, mais si vous consultez la FAQ Ruby ici: http://arc.apotheon.org/ruby/faq/rubyfaq-2.php

Section 2.3 "Quand une variable locale devient-elle accessible?" montre le comportement actuel.

Pour contourner le problème de la portée, l'une des choses légèrement "hacky" que vous devez actuellement faire est:

Il est recommandé de mettre une instruction d'affectation comme a = nil avant d'accéder à une variable locale pour ne pas être gêné par un tel comportement de variables locales.

Je crois que 1.9 supprimera la nécessité de le faire, et cela pourrait être l'un des moteurs du nouveau comportement.