On Fri, Jan 28, 2011 at 3:17 AM, Robert Klemme
<shortcutter / googlemail.com> wrote:
> On Thu, Jan 27, 2011 at 8:48 PM, Ben Bleything <ben / bleything.net> wrote:
>> Ruby does not support method overloading. Searching the list archives
>> should turn up plenty of explanations.
>
> For example the recent thread
>
> http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/377008?376902-377590
>
> and especially
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/377075

FWIW, I'd love for Ruby to support operator overloading. JRuby
supports it in Java-based Ruby methods (like the core classes) by
splitting the arities up into different call paths. I hope to do the
same under the covers for "overloaded" optional args forms, so that
this:

def foo(a, b = 1, c = 2)

would compile to the equivalent of this overloaded form:

def foo(a) foo(a, 1, 2)
def foo(a, b) foo(a, b, 2)
def foo(a, b, c) ...

When you look at optional args that way it doesn't seem so odd to take
the next leap and say ruby should allow separate logic for those
different paths rather than simply chaining them. For example, it's
uncommon but sometimes you'll see this form:

def foo(a, b = (c = true; 1)) ...

'b' is an optional arg that, when set to its optional value (i.e.
nothing passed in), also sets c = true. So you can check c to see if
the value of b came from the optional value or not. Gross!

If instead you could actually overload, it would simply be two methods:

def foo(a); b = 2; <logic for one-arg call>
def foo(a, b); <logic for two-arg call>

The fact that people have to use tricks like b = (c = true; 2) make me
think there's an opportunity here.

And it would be even cooler if Ruby supported some form of type-driven
pattern matching, so you could have different method bodies for
different input types rather than checking them over and over again.
But that's a post for another day :)

- Charlie