En Ruby, ¿por qué una igualdad con nil ("Date.new == nil") devuelve nil?

Question

Al escribir algunos rspec hoy, me encontré con un comportamiento inesperado al comparar las instancias de fecha (y tiempo) en nil. He aquí una muestra usando rubí en bruto (sin rieles u otras bibliotecas):

user@MacBook-Work ~ $ ruby -v 
ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0] 
user@MacBook-Work ~ $ irb 
>> 1 == nil 
=> false 
>> "string" == nil 
=> false 
>> :sym == nil 
=> false 
>> false == nil 
=> false 
>> [] == nil 
=> false 
>> {} == nil 
=> false 
>> Proc.new {} == nil 
=> false 

Hasta ahora, todo va bien, ¿verdad?

>> Date.new == nil 
=> nil 
>> Time.new == nil 
=> nil 

Fecha hace poner en práctica su propia ===, que funciona bien:

>> Date.new === nil 
=> false 

¿Hay alguna explicación de por qué sucede esto o por qué se desea esto comportamiento? == parece implementarse desde Comparable. ==, sin embargo, la documentación sobre eso no da ninguna indicación de que alguna vez devolvería nulo. ¿Cuál es la decisión de diseño para esto?

¡Actualización! Este no es el caso en 1.9.2:

$ irb 
ruby-1.9.2-p136 :001 > require 'date' 
=> true 
ruby-1.9.2-p136 :002 > Date.new == nil 
=> false 
ruby-1.9.2-p136 :003 > Time.new == nil 
=> false 

Answer 1

he comprobado el origen y esto es lo que descubrí:

Los operadores de comparación definidos por Comparable todo el uso de la función junto con rb_cmpint<=>. rb_cmpint genera una excepción cuando uno de los operandos es nulo.

Por lo que los operadores de Comparable plantean una excepción si el rhs no es comparable al lhs. Es decir. 5 < 2 es falso, pero 5 < "la" genera una excepción. Lo hacen para diferenciar entre los casos donde < no es verdadero porque el rhs es más pequeño y los casos en los que no es verdadero porque el rhs no es comparable. O en otras palabras: cuando x < y es falso, implica que x >= y es verdadero. Entonces, en los casos en que ese no sería el caso, arroja una excepción.

== levantar una excepción sería malo, porque == generalmente no requiere (y no debería) que sus operandos sean comparables. Sin embargo, == usa el mismo método que los otros operandos, lo que genera una excepción. Entonces, toda la función simplemente está envuelta en un rb_rescue. Y eso devuelve nil si se lanza una excepción.

Tenga en cuenta que esto solo se aplica a ruby ​​1.8. Esto se ha corregido en 1.9 y ahora == nunca devuelve nil (excepto, por supuesto, si define su propio == que sí lo hace).

Answer 2

La clase Date incluye el método Comparable#==, pero ese método invoca el método del receptor <=>. En este caso, es Date#<=>, que espera otro objeto Date. Cuando recibe nil, devuelve nil. Este comportamiento ciertamente parece inconsistente, y no sé las razones detrás de esto.

Answer 3

Si depende de esto para el código, ¿siempre puede usar el .nil? método al que responde cualquier objeto Ruby.

>> Date.new.nil? 
=> false 

Answer 4

Sucede porque no puede comparar cosas que no están definidas. Es deseable porque si al menos uno de tus operandos no está definido, entonces no puedes sacar ninguna conclusión sobre el resultado, que es diferente de afirmar la verdad.

Muchos idiomas tratan igual y falso, lo que es sospechoso es puramente por conveniencia. Ciertamente no es matemáticamente correcto.