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
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
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.
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).
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.
···
From my understanding, taking the number of arguments, runtime type of
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......
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
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 Mon, Jan 17, 2011 at 7:09 PM, Su Zhang <zhangsu@live.com> wrote:
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:
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.
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
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:
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 <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).