Why comparing to null is so unstable?
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
Copyright (c) Microsoft Corporation. All rights reserved.
>>> require 'System'
>>> i = System::Int32.MinValue
>>> d = System::DateTime.Now
=> 11.02.2010 14:15:02
(ir):1: can't convert NilClass into System::DateTime (TypeError)
In 9.1 this code works as expected.
As far as I can tell, the inconsistency is because
System.DateTime defines it's own == method, and
System.Int32 does not.
System.Int32 is a "special" class in that IronRuby maps it directly to
Fixnum, so when you call
System.Int32 == x, you're actually calling the built in
With that in mind, here's what happens:
Int32, which maps to
x = System::Int32.MinValue # => -2147483648 x.class # => Fixnum x == nil # => Fixnum == nil
Int16 which doesn't map to anything, and does not overload
x = System::Int16.MinValue # => -32768 (Int16) x.class # => System::Int16 x == nil # => Object == nil
DateTime which doesn't map, but does overload
x = System::DateTime.Now # => 1/03/2010 9:00:47 a.m. x.class # => System::DateTime x == nil # System::DateTime == nil
== method only accepts other
IronRuby then tries to convert
nil to one of these structures so it can call the method, which then fails with the error you see.
Does this appear inconsistent? Yes.
Is it actually inconsistent? I'd argue no. Well, no more inconsistent than any other CLR type that defines it's own
== method. To me it makes no sense to just have a special case for
In general though, it doesn't matter. The "correct" way to check for null in ruby is to call
.nil?, and this works well with
DateTime or any other class/struct