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.

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 [email protected] 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.

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…

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang [email protected] 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

On Tue, Jan 18, 2011 at 2:09 AM, Su Zhang [email protected] 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs