Perché se le dichiarazioni non introducono l'ambito in ruby ​​1.9?


Risposte:


9

Due motivi per cui ciò è 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 ifistruzioni no scope ti consentono di fare è definire cose nel tuo codice sorgente a cui è possibile accedere al di fuori dell'istruzione if.

Primo esempio: sostituire i metodi

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

In questo esempio, ci sono due diverse definizioni per il namemetodo. Uno che verrà utilizzato se il String.encodemetodo esiste e uno (implementazione inferiore) che verrà utilizzato se il metodo di codifica non esiste. In sostanza, ciò consente di utilizzare una stringa codificata correttamente se supportata dalle librerie.

Secondo esempio: sostituire l'implementazione

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

In questo esempio, stiamo fornendo una classe / modulo completamente diverso a seconda dell'esistenza di una funzione di libreria. Ciò consente di disporre di un algoritmo completamente diverso che utilizza una nuova funzione di libreria pur ricadendo su un algoritmo meno efficiente o completo che è abbastanza vicino se non esiste.

L'importantissimo perché

Quindi cosa ti compra questo? Se l' ifistruzione introduce un nuovo ambito, il nuovo metodo o classe esisterebbe e verrebbe utilizzato solo entro i limiti ifdell'istruzione. Questo vincolo rende molto difficile supportare una libreria che avrà bisogno di modifiche per Ruby 2.0 mentre migreremo dall'1.9 in futuro.

Con entrambi gli esempi forniti nella presentazione a cui ti sei collegato, il ragionamento è mantenere una base di codice per le tue librerie pur supportando 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 la 2.0, sarai comunque in grado di supportare i tuoi utenti in caso di modifiche incompatibili. Credo che ce ne fossero alcuni tra 1.9.1 e 1.9.2. Ce ne saranno di più in futuro.


1

Non sono un esperto, ma se dai un'occhiata alle FAQ su Ruby qui: http://arc.apotheon.org/ruby/faq/rubyfaq-2.php

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

Per aggirare il problema di scoping, una delle cose leggermente "confuse" che devi attualmente fare è:

Si consiglia di inserire un'istruzione di assegnazione come a = nil prima di accedere a una variabile locale per non essere disturbati da tale comportamento delle variabili locali.

Io credo che 1,9 eliminerà la necessità di fare questo, e questo potrebbe essere uno dei driver per il nuovo comportamento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.