[Ironruby-core] Fixnum Patch
Peter Bacon Darwin
bacondarwin at googlemail.com
Wed Dec 12 16:33:01 EST 2007
What John discusses below was part of the reason I was wary (not weary!) of
using Nullable types.
I have now tested it and if you have a method that, for instance, returns
int? then on the occasions that null is returned that class of the resulting
object is NilClass and when it is not null, the class is Fixnum. So all
seems to be well and I am happy to fix-up those methods in Bignum and Fixnum
that should use Nullable types when I next submit a patch.
Thanks for pointing this out.
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Messerly
Sent: Wednesday,12 December 12, 2007 21:08
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Fixnum Patch
Brian J. Cardiff wrote:
> I agree in the pros of using nullable: Clarity and Performance.
> Also my previous mail was inspired in what your original need: returns
> int or null, so using Nullable<int> it seems to be the smallest
> solution. But I didn't have in mind if there are some issues in
> exposing them to the ruby engine.
Definitely a good thing to do--as long as we actually handle Nullable<int>
correctly. Off the top of my head I'm not sure. Worth trying though.
For better or worse, there are a lot of methods that need to have their
return types typed to System.Object. Methods that take blocks usually need
to return object (in case the block breaks with an arbitrary object, which
we need to pass through). Also if you're calling back through a dynamic site
into Ruby code, even if the method should normally return a particular type
(for example, <=> is supposed to return Fixnum +1, 0, or -1), nothing stops
the user from returning whatever they want. We actually don't get this right
today in several places.
(Ah, the fun of implementing a dynamically typed language in a statically
typed one :-) )
Ironruby-core mailing list
Ironruby-core at rubyforge.org
More information about the Ironruby-core