Solución:
Creo que la respuesta a su pregunta actualizada se puede explicar con ejemplos explícitos. En el siguiente ejemplo, tiene parámetros opcionales en un orden explícito:
def show_name_and_address(name="Someone", address="Somewhere")
puts "#{name}, #{address}"
end
show_name_and_address
#=> 'Someone, Somewhere'
show_name_and_address('Andy')
#=> 'Andy, Somewhere'
El enfoque de parámetro nombrado es diferente. Aún le permite proporcionar valores predeterminados, pero le permite a la persona que llama determinar cuál de los parámetros, si corresponde, proporcionar:
def show_name_and_address(name: "Someone", address: "Somewhere")
puts "#{name}, #{address}"
end
show_name_and_address
#=> 'Someone, Somewhere'
show_name_and_address(name: 'Andy')
#=> 'Andy, Somewhere'
show_name_and_address(address: 'USA')
#=> 'Someone, USA'
Si bien es cierto que los dos enfoques son similares cuando no se proporcionan parámetros, difieren cuando el usuario proporciona parámetros al método. Con los parámetros con nombre, la persona que llama puede especificar qué parámetro se proporciona. Específicamente, el último ejemplo (que proporciona solo la dirección) no se puede lograr en el primer ejemplo; puede obtener resultados similares SÓLO proporcionando AMBOS parámetros al método. Esto hace que el enfoque de los parámetros con nombre sea mucho más flexible.
En primer lugar, el último ejemplo que publicó es engañoso. Estoy totalmente en desacuerdo con que el comportamiento sea similar al anterior. El último ejemplo pasa el hash del argumento como el primer parámetro opcional que es una cosa diferente.
Si no desea tener un valor predeterminado, puede usar nil.
Si desea leer un buen artículo, consulte “Argumentos de palabras clave de Ruby 2”.
Estoy de acuerdo con usted en que es extraño requerir valores predeterminados como precio por usar parámetros con nombre, ¡y evidentemente los mantenedores de Ruby están de acuerdo con nosotros! Ruby 2.1 eliminará el requisito de valor predeterminado a partir de 2.1.0-preview1.