Perché se le istruzioni non introducono scope in ruby 1.9?

Due motivi per cui questo è stato fatto in Ruby 1.9 sono nelle seguenti diapositive, anche se potrebbe non essere ovvio senza la finestra di dialogo del presentatore. Due cose che le istruzioni no scope if ti consentono di definire le cose nel tuo codice sorgente a cui è possibile accedere al di fuori dell'istruzione if.

Primo esempio: sostituisci metodi

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

In questo esempio, esistono due diverse definizioni per il metodo name . Uno che verrà utilizzato se esiste il metodo String.encode e uno (implementazione inferiore) che verrà utilizzato se il metodo di codifica non esiste. In sostanza, questo ti permette di usare una stringa correttamente codificata se le librerie lo supportano.

Secondo esempio: Sostituisci implementazione

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

In questo esempio, stiamo fornendo una classe / modulo completamente differente a seconda che esista una funzione di libreria. Questo ti permette di avere un algoritmo completamente diverso che usa una nuova funzione di libreria mentre ancora ricade su un algoritmo meno efficiente o completo che è abbastanza vicino se non esiste.

Tutto ciò che è importante perché

Quindi cosa ti compra? Se l'istruzione if ha introdotto un nuovo ambito, il nuovo metodo o classe esisterà e verrà utilizzato solo all'interno dei limiti dell'istruzione if . Questo vincolo rende molto difficile supportare una libreria che necessiterà di modifiche per Ruby 2.0 mentre migriamo da 1.9 in futuro.

Con entrambi gli esempi forniti nella presentazione a cui sei collegato, il ragionamento è di mantenere una base di codice per le tue librerie pur continuando a supportare più versioni di Ruby. Credo che sia nato dal dolore della transizione tra Ruby 1.8 e Ruby 1.9. Dato che il team di Ruby sta marciando costantemente verso il 2.0, sarai comunque in grado di supportare i tuoi utenti in caso di modifiche incompatibili. Credo ci fossero alcuni tra 1.9.1 e 1.9.2. Ce ne saranno altri in futuro.

Non sono esperto, ma se dai un'occhiata alle FAQ di Ruby qui: link

Sezione 2.3 "Quando diventa accessibile una variabile locale?" mostra il comportamento corrente.

Per aggirare il problema dell'ambito, una delle cose leggermente "hacky" che devi fare attualmente è:

You are recommended to put an assignment statement like a = nil before accessing a local variable not to be bothered by such behaviour of local variables.

I credo che 1.9 rimuoverà la necessità di farlo, e questo potrebbe essere uno dei driver per il nuovo comportamento.