Forum: Ruby Why Ruby Does Not Support Method Overloading?

Hi Sir's,


I have taken one class with two overloading methods i.e same method name
with different number of arguments and i invoke with instance of class i
got wrong number of arguments error. please see the below code......

class Person

  def print_details(name)
    "Hey My Name is #{name}"
  end

  def print_details(name,age)
    "Hey My Name is #{name} and #{age}"
  end
end

person1 = Person.new
puts person1.print_details("peter")
puts person1.print_details("pk",25)

 I got The error  wrong number of arguments (1 for 2) (ArgumentError).

  Why Ruby does not support the method overloading ???

  Could u please explain me reason????

Thanking You in Advance........

There may be only one method with given name in Ruby class. If several
methods with the same name defined in the class - the latest overwrites
previous definitions.

However, you may emulate methods overloading like this:

class Person

  def print_details(*args)
    case args.size
    when 1
      "Hey My Name is #{args[0]}"
    when 2
      "Hey My Name is #{args[0]} and #{args[1]}"
    end
  end

end

I think you got the idea.

> class Person
>
> def print_details(name)
>  "Hey My Name is #{name}"
> end
>
> def print_details(name,age)
>  "Hey My Name is #{name} and #{age}"
> end
> end

You can use default arguments in this case.

def print_details(name, age = nil)
  s = "Hey My Name is #{name}"
  s << " and age #{age}" if age
  puts s
end

A piece of advice - A function's name and action should match. In this
case, you name the method print_detail but do not print it. Seems like
you expect to use the return value elsewhere; call the method just
'details' in that case.

> person1 = Person.new
> puts person1.print_details("peter")
> puts person1.print_details("pk",25)
>
> I got The error wrong number of arguments (1 for 2) (ArgumentError).

Yeah. The second definition now binds to 'print_details'.

> Why Ruby does not support the method overloading ???

Thats the Ruby way. Ruby makes up for function overloading with its
flexible argument processing ability, like Victor pointed out.

Victor D. wrote in post #975387:
> There may be only one method with given name in Ruby class. If several
> methods with the same name defined in the class - the latest overwrites
> previous definitions.
>
> However, you may emulate methods overloading like this:
>
> class Person
>
>   def print_details(*args)
>     case args.size
>     when 1
>       "Hey My Name is #{args[0]}"
>     when 2
>       "Hey My Name is #{args[0]} and #{args[1]}"
>     end
>   end
>
> end
>
> I think you got the idea.


Ok Thank Your

Yes it is overwriting the previous function with current function bases 
on method name . it is not considering arguments, only it is considering 
method name.......
So Ruby is supporting Method Over writing not method overloading...
Thank You for giving me an idea......

Method overloading is ideally a feature only for statically typed
language, in which the binding of method names can be easily made at
compile time. Function/method names as well as the statically typed
formal parameters are all parts of the formal names used during early
binding. However, with a dynamically typed language (especially those
who have a method dispatch implementation similar to Smalltalk), only
the method name is considered part of the formal message content during
method dispatch (late binding).

From my understanding, taking the number of arguments, runtime type of
arguments or even the formal parameter names into account for message to
method mapping will complicate the language implementation. This is also
the reason why Ruby does not support multiple dispatch at the language
level. Common-Lisp does support multiple dispatch, but it does so by
including a type modifier to the arguments so that they can be checked
against the actual runtime type of arguments, which, IMO, is as 
unpleasant as doing something like the following in a single method 
definition:

case arg
when String
    # ...
when Symbol
    # ...
end

Like Anurag said, Ruby already has a flexible argument processing
ability; it suffices our needs though in a different style.

On Mon, Jan 17, 2011 at 7:09 PM, Su Zhang <zhangsu@live.com> wrote:

>    # ...
> end
>
>
I went through a Lisp book over the winter break, and I took it a 
different
way: that it was essentially a way to define a receiver for a function. 
(not
sure if that is good terminology)

In other words, I took it like:
class Array
  def size
    Array size finding code
  end
end

class Hash
  def size
    Hash size finding code
  end
end

Now, hash.size invokes a different method than array.size. So in Lisp 
this
would maybe look like

(defmethod size ((self array))
  array size finding code )

(defmethod size ((self hash-table))
  hash-table size finding code )

And unlike all the other functions in Lisp, which share the same 
namespace,
size knows which function to invoke (size ary) invokes a different 
function
than (size hash). So I think that defmethod is an appropriate name, 
because
that is how I consider them, modular like methods, as opposed to created 
in
one canonical place like a case statement.

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang <zhangsu@live.com> wrote:
> From my understanding, taking the number of arguments, runtime type of
> arguments or even the formal parameter names into account for message to
> method mapping will complicate the language implementation.

... and method lookup tables will potentially be larger.  Dunno
whether this is a critical factor though.

>  # ...
> when Symbol
>  # ...
> end

For multiple arguments the unpleasant variant looks like this (1.9 and 
later):

def f(*args)
  case args.map(&:class)
  when [Array, Array]
    puts "Array * 2"
  when [String, Array]
    puts "String, Array"
  when [Hash]
    puts "Hash"
  else
    raise ArgumentError, "Don't know what to do with %p" % [args]
  end
end

Cheers

robert

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang <zhangsu@live.com> wrote:
> Method overloading is ideally a feature only for statically typed
> language, in which the binding of method names can be easily made at
> compile time. Function/method names as well as the statically typed
> formal parameters are all parts of the formal names used during early
> binding. However, with a dynamically typed language (especially those
> who have a method dispatch implementation similar to Smalltalk), only
> the method name is considered part of the formal message content during
> method dispatch (late binding).

There is also a more fundamental reason to consider disallowing method
overloading with different argument signatures: each method that
shares the same name (identifier) should do the same.  If however
arguments have different types methods cannot do the same - strictly
speaking.  Of course, this is an extreme point of view but you have to
ask yourself where you draw the line for "same".

In languages with interfaces (e.g. Java) ideally all appropriate
argument types implement the same interface and you need only one
method anyway - or all argument types inherit from a common base
class.

In Ruby however which has duck typing you can pass in anything as long
as "anything" responds to all methods needed - hence there is less
demand for overloading.  You can do

class IntSum
  def initialize; @s = 0; end

  def add(x)
    @s += x.to_int # or x.to_i
  end
end

where you would need multiple methods for different argument types in
other languages.

Kind regards

robert