Ruby per loop una trappola?

Question

In una discussione sui loop di Ruby, è stato recentemente parlato di Niklas B. per il ciclo "non introduce un nuovo ambito", rispetto a ciascun ciclo. Mi piacerebbe vedere alcuni esempi di come si sente questo.

O.K., espongo la domanda: in quale altro punto di Ruby vediamo quali apri fanno/delimitano i blocchi di fine, ma in realtà non vi è alcuno scopo all'interno? Qualcos'altro oltre a ... do ... fine?

O.K., Un'ulteriore espansione della domanda, c'è un modo per scrivere per il ciclo con parentesi graffe {blocco}?

Answer 1

Illustriamo il punto con un esempio:

results = [] 
(1..3).each do |i| 
    results << lambda { i } 
end 
p results.map(&:call) # => [1,2,3] 

fresco, questo è ciò che ci si aspettava. Ora verifica quanto segue:

results = [] 
for i in 1..3 
    results << lambda { i } 
end 
p results.map(&:call) # => [3,3,3] 

Huh, che sta succedendo? Credimi, questi tipi di bug sono cattivi da rintracciare. Gli sviluppatori Python o JS sapranno cosa intendo :)

Questo solo è un motivo per me per evitare questi cicli come la peste, anche se ci sono più buoni argomenti a favore di questa posizione. Come Ben ha sottolineato correttamente, l'utilizzo del metodo corretto da Enumerable porta quasi sempre a un codice migliore rispetto all'utilizzo di semplici vecchi, imperativi cicli for o fancier Enumerable#each. Ad esempio, l'esempio precedente potrebbe anche essere conciso scritto come

lambdas = 1.upto(3).map { |i| lambda { i } } 
p lambdas.map(&:call) 

espando la domanda: quale altro in Ruby vediamo cosa fare apears/blocco delimitatori finali, ma non c'è in realtà alcuna portata dentro? Qualcos'altro oltre a ... do ... fine?

Ogni singolo uno dei costrutti di loop può essere utilizzato in questo modo:

while true do 
    #... 
end 

until false do 
    # ... 
end 

D'altra parte, possiamo scrivere ogni uno di questi senza la do (che ovviamente è preferibile):

for i in 1..3 
end 

while true 
end 

until false 
end 

Un'altra espansione della domanda, c'è un modo per scrivere per ciclo con parentesi graffe {} blocco

No, non c'è. Si noti inoltre che il termine "blocco" ha un significato speciale in Ruby.

Answer 2

Bene, anche i blocchi non sono perfetti in Ruby precedenti alla 1.9. Non sempre introducono nuovo ambito di applicazione:

i = 0 
results = [] 
(1..3).each do |i| 
    results << lambda { i } 
end 
i = 5 
p results.map(&:call) # => [5,5,5] 

Answer 3

In primo luogo, vi spiego il motivo per cui non si vuole utilizzare for, e poi spiegare perché si potrebbe.

Il motivo principale per cui non si desidera utilizzare for è che non è univoco. Se si utilizza each, è possibile sostituire facilmente lo each con uno map o uno find o uno each_with_index senza una modifica importante del codice. Ma non c'è for_map o for_find o for_with_index.

Un altro motivo è che se si crea una variabile all'interno di un blocco entro each e non è stata creata in precedenza, rimarrà in esistenza per tutto il tempo che il ciclo esiste. Liberarsi delle variabili una volta che non le usi, è una buona cosa.

Ora ti accennerò perché potresti voler usare for. each crea una chiusura per ogni ciclo e se ripeti quel ciclo troppe volte, quel loop può causare problemi di prestazioni. In https://stackoverflow.com/a/10325493/38765, ho pubblicato che utilizzando un ciclo while anziché un blocco reso più lento.

RUN_COUNT = 10_000_000 
FIRST_STRING = "Woooooha" 
SECOND_STRING = "Woooooha" 

def times_double_equal_sign 
    RUN_COUNT.times do |i| 
    FIRST_STRING == SECOND_STRING 
    end 
end 

def loop_double_equal_sign 
    i = 0 
    while i < RUN_COUNT 
    FIRST_STRING == SECOND_STRING 
    i += 1 
    end 
end 

times_double_equal_sign preso costantemente 2,4 secondi, mentre loop_double_equal_sign era costantemente 0,2 e 0,3 secondi più veloce.

In https://stackoverflow.com/a/6475413/38765, ho trovato che l'esecuzione di un ciclo vuoto richiedeva 1,9 secondi, mentre l'esecuzione di un blocco vuoto richiedeva 5,7 secondi.

Sapere perché non si desidera utilizzare for, sapere perché si desidera utilizzare for e utilizzare solo quest'ultimo quando è necessario. A meno che non provi nostalgia per altre lingue. :)