>From: jmichel / schur.institut.math.jussieu.fr (Jean Michel)
>Subject: [ruby-talk:8249] Re: My first impression of Ruby. Lack of overloading? (long)

> >Erhm ... what? Lack of overloading? Impossible ... ah you mean
> >overloading by parameter type, yes? That is indeed not available in
> >Ruby (nor in Python or Smalltalk, BTW). The reason is that variables
> >are not typed in such languages. Therefore it is difficult (perhaps
> >impossible in some cases?) for the compiler to fiddle out on
> >compilation time what kind of method to be called later on!
> 
> At compilation time, no. But at interpretation time, certainly each object
> has a type (class)

So complex.rb does run-time parameter check.  Below I write
simplified version of Complex class in C++ and Ruby.  Both of
them have almost same capability.  Is Ruby version clumsier?
I don't think so.  Major difference is parameter type check;
compile-time or run-time.

C++ version:

class complex {
  double real, imag;
public:
  complex(double a, double b=0) {
    real = a;
    imag = b;
  }
  complex operator+(complex a) {
    return complex(real+a.real, imag+a.imag);
  }
  complex operator+(double a) {
    return complex(real+a, imag);
  }
};

Ruby version:

class Complex
  attr_accessor(:real, :imag)
  def initialize(a, b=0)
    @real = a
    @imag = b
  end
  def +(a)
    case a
    when Complex
      Complex.new(@real+a.real, @imag+a.imag)
    when Numeric
      Complex.new(@real+a, @imag)
    end
  end
end

> However, one then has a concern about efficiency. If too much is implemented
> in the library the language becomes less efficient. I guess I have to
> see in practice how the efficiency works out for a large mathematical
> project...

Yes, run-time check spends execution time.
But Ruby has more flexibility like this:

% irb -r complex -r rational
irb(main):001:0> 1/Complex(Rational(3,2),1)
Complex(Rational(6, 13), Rational(-4, 13))

I think this kind of flexibility is big advantage
when the library grows.

M.Tanaka