Una nueva característica llamada “parámetros numerados” verá la luz del día en la versión Ruby 2.7 a finales de año. Lo que me llamó la atención no fue la característica en sí, sino la recepción mixta que recibió de la comunidad.

Parámetros de bloque

Cada vez que abre un bloque tiene la oportunidad de pasar una lista de parámetros numerados

object.method { |parameter_1, parameter_2, ... parameter_n| ... }

Por ejemplo, si estuviera iterando sobre un hash para imprimir sus claves con valores coincidentes, haría algo como esto:

my_hash.each { |key, value| puts "#{key}: #{value}" }

Parámetros numerados

Con los nuevos parámetros numerados, podrá ahorrarse algunas pulsaciones de teclas y usar @ seguido del número que representa la posición del parámetro que desea usar, por lo que nuestro código anterior ahora se vería así:

my_hash.each { puts "#{@1}: #{@2}" }

Sin nombre de variable predeterminado

Otros idiomas como Kotlin usan it como el nombre de variable predeterminado dentro de un bloque.

collection.map { println(it) }

Este no es el caso con esta nueva característica.

object.method { p @1 }

es azúcar sintáctico para

object.method { |parameter_1,| p parameter } 

y no para

object.method { |parameter| p parameter } 

Por lo tanto, preste atención al conjunto de datos que está transfiriendo porque podría obtener un comportamiento inesperado como este:

[1, ['a', 'b'], 3, {foo: "bar"}].map { @1 }
=> [1, "a", 3, {:foo=>"bar"}]

Como puede ver, 1 y 3 se toman como el primer parámetro numerado como se esperaba. Cada elemento de la matriz se convierte en uno de los parámetros numerados, por lo que @1 => 'a', @2 => 'b'. Y el hash se trata como un solo objeto, por lo que tampoco se dividirá.

Esto no debería ser una sorpresa ya que es el comportamiento esperado de hacer

[1, ['a', 'b'], 3, {foo: "bar"}].map { |x,| x }

pero en este caso dejamos claro al lector cuando decimos |x,| . No hay ningún plan para convertirlo en un nombre de variable predeterminado que es extraño porque eso es exactamente lo que se solicitó en la solicitud original.

La compatibilidad con versiones anteriores es de alta prioridad

Como ya mencioné, esto es lo que la persona que solicitó el problema quería tener, pero no fue aceptado en su forma original debido a la compatibilidad con versiones anteriores. La introducción de nuevas palabras clave al lenguaje Ruby es una opción prohibida en este momento porque Matz no es fanático de romper el código antiguo de los desarrolladores con versiones más nuevas de Ruby.

Aprecio que Matz adopte una postura tan fuerte sobre este asunto, creo que es importante actualizar sus bases de código para usar la última versión de Ruby, pero cuanto más difícil sea hacer una actualización, menos probable es que termine haciéndolo. Entonces, si actualizo a Ruby 2.7 y empiezo a ver cambios importantes en todas partes en mi base de código, voy a ponerlo en espera el mayor tiempo posible. En cambio, esta experiencia debería ser acogedora.

¿Dolor o ganancia?

No sé cuántas veces pasa una lista de parámetros a un bloque versus cuántas veces pasa un solo parámetro, pero estoy bastante seguro de que en cada base de código puede encontrar muchas más instancias de este último que el primero. Entonces la pregunta es: ¿Qué tan valiosa es esta nueva característica?

A nadie parece gustarle el hecho de que los parámetros numerados comienzan con @ y algunos miembros de la comunidad también dicen que los desarrolladores podrían confundirse pensando que los parámetros numerados son variables de instancia.

Actualmente hay un problema abierto que solicita reconsiderar los parámetros numerados porque en su estado actual trae más dolor que valor. ¿Qué piensas? ¿Te gustan los parámetros numerados? ¿Crees que deberían implementarse de una manera diferente? ¿Prefieres no tenerlos? Hay una vótacón informal en caso de que quiera participar.