>Cool down.  Ruby remains to be Ruby in the future.  Even in the case I
>would add the overloading based on argument types, it certainly would
>be optional.  And you will know it's far from static typing.

Surely the fact that one can write code like ...

	def fred(value)
		case value.type

			when 'X'

			when 'Y'
		end
	end

means the programmer can get the same effect as with overloading, just
with a tiny bit more work.  I've been doing stuff like this a lot
recently, to get things like multiplication of different kinds of
numbers (rational, complex, Fixnum) to do the right conversions and
return the right type/value.  I'm not sure I'm writing the best code,
but at least I can achieve what I need.

I was absolutely amazed when I tried something "just for fun" and it
worked immediately, with no work on my part.  I created some complex
numbers with the components passed to new() being rational numbers and
addition, multiplication etc. just worked in the manner they should.

I then tried sticking some of those complex numbers into a matrix
class I'd written and, sure enough, it all just worked again!  If I'd
been writing this in C++, I would have had to make certain I had all
these types descending from a common base and goodness knows what
else.

In this case, Ruby's untyped-ness was a real boon!

As I say, I had to do a small amount of fiddling, for example, to get
Rational#+() to do the right thing if the RHS was something other than
a Rational etc., but it was fairly minimal and generally came down to
constructing objects of the appropriate type (ie, the next most
specific one) from the data I had, but that was nothing compared to
the amount of effort I'd have put in to get this working in, say, C++.