# Why Ruby Does Not Support Method Overloading?

**URL:** <https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878>\
**Category:** Ruby\
**Created:** [January 17, 2011, 6:38am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878 "2011-01-17T06:38:14Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [January 17, 2011, 6:38am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/1 "2011-01-17T06:38:14Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 17, 2011, 8:31am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/2 "2011-01-17T08:31:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 17, 2011, 8:50am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/3 "2011-01-17T08:50:09Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 18, 2011, 2:09am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/4 "2011-01-18T02:09:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 18, 2011, 2:36am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/5 "2011-01-18T02:36:55Z")

</div>

On Mon, Jan 17, 2011 at 7:09 PM, Su Zhang [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 17, 2011, 10:22am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/6 "2011-01-17T10:22:05Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 18, 2011, 10:28am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/7 "2011-01-18T10:28:02Z")

</div>

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![peterk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7993a0/32.png) [@peterk](https://www.ruby-forum.com/u/peterk)\
**Post date:** [January 18, 2011, 9:02am UTC](https://www.ruby-forum.com/t/why-ruby-does-not-support-method-overloading/201878/8 "2011-01-18T09:02:38Z")

</div>

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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
