From: Gary Wright <gwtmp01@...>
Date: 2011-02-01T12:10:32+09:00
Subject: Re: why is overloading invalid in ruby.


On Jan 31, 2011, at 2:47 PM, Charles Oliver Nutter wrote:

> On Mon, Jan 31, 2011 at 1:27 PM, Thomas E Enebo <tom.enebo@gmail.com> wrote:
>> On Mon, Jan 31, 2011 at 9:00 AM, Gary Wright <gwtmp01@mac.com> wrote:
>>> I think the original poster provided an example of overloading based on the number of parameters but not their type.
>>> Even restricting yourself to overloading by arity is a bit problematic in Ruby because the arity still has to be determined (in some cases) dynamically:
>> Actually, arity of callsite is always calculated  in Ruby to know if
>> you should throw an ArgumentError (3 for 0 specified sort of errors)

Maybe I'm overlooking something but I wasn't suggesting that you don't need to calculate arity but instead was pointing out that you can't just calculate it at parse time but sometimes need to calculate it at call time.

foo(1,2)     # the call arity can be computed at parse time
foo(*a)      # the call arity must be computed at call time

So in an 'overload-based-on-arity' scheme there might be some optimization opportunities for some call sites but not for every call site.

Seems like you can get pretty far though with just a little meta-programming with no special language support:

module Arity
  def overload(base)
    define_method(base) do |*args|
      argc = args.size
      method_name = "#{base}_#{argc}"
      if respond_to?(method_name)
        send(method_name, *args)
      else
        raise ArgumentError, "wrong number of arguments (no method for #{argc} arguments)"
      end
    end 
  end
end

class A
  extend Arity

  overload :foo

  def foo_0
    puts "foo with no arguments"
  end

  def foo_1(arg1)
    puts "foo with 1 argument: #{arg1.inspect}"
  end

end

A.new.foo           # dispatches to A#foo_0
A.new.foo(1)        # dispatches to A#foo_1
A.new.foo(1,2)      # ArgumentError


Gary Wright