[Ironruby-core] Fixnum Patch

Brian J. Cardiff bcardiff at gmail.com
Wed Dec 12 11:32:14 EST 2007


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.

On Dec 12, 2007 11:56 AM, Peter Bacon Darwin <bacondarwin at googlemail.com> wrote:
>
>
>
>
> Brian J. Cardiff wrote:
>
> > wouldn't be better to use nullable types? So, for example, it would be
>
> > clear that the result is either null or int, and there is not
>
> > propagation of casts.
>
>
>
>
>
> This is a fair comment and one that I did consider.
>
>
>
> I am generally a bit weary of Nullable types and I didn't feel overly
> confident in using them in library code (how often do you actually see them
> used in practice?).  This is no excuse of course.
>
>
>
> The two reasons in favour of using NullableTypes as I see them are clarity
> and performance.
>
>
>
> Clarity
>
> Ruby doesn't really appear to care much about the return type on the method
> itself; it is more interested in the object that is returned; and so the
> user of the class (in Ruby) won't be able to tell the difference anyway.
> There are other cases where object is returned regularly
>
> In fact almost all the Bignum methods return object since the result may
> well be converted to a Fixnum (if it is small enough) or even a Float (if
> the result is not supposed to be Integer).
>
>
>
> Performance
>
> In the end there is not much gained in using more specific types in these
> cases.  The only reason would be for performance (saving the cost of Boxing
> or casting) but to get to the value of a Nullable type you still have to
> check whether it is null and then access the Value property anyway so there
> is probably not much in it.
>
>
>
> public int? Compare(BigInteger self, BigInteger other)
>
> leads to code like
>
> int? result = Compare(someBigInt, otherBigInt);
>
> if (result.HasValue) {
>
>       int actualResult = result.Value
>
>       // Do something with it
>
> } else {
>
>       // Do something with null
>
> }
>
>
>
> public object Compare(BigInteger self, BigInteger other)
>
> leads to code like
>
> object result = Compare(someBigInt, otherBigInt);
>
> if (result is int) {
>
>       int actualResult = (int)result;
>
>       // Do something with it
>
> } else {
>
>       // Do something with null
>
> }
>
>
>
> The main reason I kept away from using them, was that it keeps the options
> open and is more in keeping with the general style of the library code.
>
>
>
> Am I barking up the wrong tree here?  I may well be missing something.  Let
> me know what you think.
>
>
>
> Pete
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>



-- 
Brian J. Cardiff
bcardiff(?)gmail.com
.


More information about the Ironruby-core mailing list