¿Cómo hacen los programadores de Ruby la verificación de tipos?

Question

Como no hay ningún tipo de rubí, ¿cómo se aseguran los programadores de Ruby de que una función reciba los argumentos correctos? En este momento, estoy repitiendo las declaraciones if object.kind_of/instance_of para verificar y aumentar los errores de tiempo de ejecución en todas partes, lo cual es feo. Debe haber una mejor forma de hacer esto.

Answer 1

Ruby es, por supuesto, tipeado dinámicamente.

Por lo tanto, la documentación del método determina el tipo de contrato; la información de tipo se mueve desde el sistema de tipo formal a la documentación del método [tipo de letra informal]. Mezclo generalidades como "actúa como una matriz" y detalles como "es una cadena". La persona que llama solo debe esperar trabajar con los tipos indicados.

Si la persona que llama viola este contrato, puede pasar cualquier cosa. El método no necesita preocuparse: se usó incorrectamente.

A la luz de lo anterior, evitar la comprobación de un tipo específico y evitar tratando de crear sobrecargas con tal comportamiento.

Pruebas unitarias pueden ayudar asegurarse de que el contrato funcione para los datos esperados.

Answer 2

Mi manera personal, que no estoy seguro si es una forma recomendada en general, es verificar y hacer otras validaciones una vez que se produce un error. Puse la rutina de verificación de tipo en un bloque de rescate. De esta forma, puedo evitar la pérdida de rendimiento cuando se dan los argumentos correctos, pero todavía devuelvo el mensaje de error correcto cuando ocurre un error.

def foo arg1, arg2, arg3 
    ... 
    main_routine 
    ... 
rescue 
    ## check for type and other validations 
    raise "Expecting an array: #{arg1.inspect}" unless arg1.kind_of?(Array) 
    raise "The first argument must be of length 2: #{arg1.inspect}" unless arg1.length == 2 
    raise "Expecting a string: #{arg2.inspect}" unless arg2.kind_of?(String) 
    raise "The second argument must not be empty" if arg2.empty? 
    ... 
    raise "This is `foo''s bug. Something unexpected happened: #{$!.message}" 
end 

Supongamos que en el main_routine, se utiliza el método each en arg1arg1 suponiendo que es una matriz. Si resulta que se trata de otra cosa, a la que no se ha definido each, el mensaje de error aparecerá como method each not defined on ..., que, desde la perspectiva del usuario del método foo, podría no ser útil. En ese caso, el mensaje de error original será reemplazado por el mensaje Expecting an array: ..., que es mucho más útil.

Answer 3

Si un método tiene un motivo para existir, se lo llamará.

Si se escriben pruebas razonables, se ejecutará todo.

Y si se llama a todos los métodos, se verificarán todos los métodos.

No pierda el tiempo realizando comprobaciones de tipo que pueden limitar innecesariamente las llamadas y solo duplicará la comprobación de tiempo de ejecución de todos modos. Pasar ese tiempo escribiendo pruebas en su lugar.

Answer 4

se recomienda utilizar el aumento en el principio del método para agregar la comprobación manual tipo, simple y eficaz:

def foo(bar) 
    raise TypeError, "You called foo without the bar:String needed" unless bar.is_a? String 
    bar.upcase 
end 

mejor manera cuando usted no tiene mucho parámetros, también una recomendación es usar palabras clave argumentos disponibles en ruby ​​2+ si tiene múltiples parámetros y observa sus detalles de implementación actuales/futuros, están mejorando la situación, dando al programador una manera de ver si el valor es nulo.

más: se puede utilizar una excepción personalizada

class NotStringError < TypeError 
    def message 
    "be creative, use metaprogramming ;)" 
#... 
raise NotStringError 

Answer 5

Se puede utilizar un enfoque Design by Contract, con la gema contracts rubí. Me parece bastante agradable.