Overloading methods question please?

Ruby
1

def do_something(a as Array)
puts “first array method”
puts a.inspect
end

def do_something(a as Hash)
puts “Second hash method”
puts a.inspect
end

def do_something(a)
puts “third method anything else”
puts a.inspect
end

a = [“something”, “something esle”]
b = {“key1” => “something”, “key2” => “something else”}
c = 1
d = ‘c’

do_something(a)
do_something(b)
do_something©
do_something(d)

what’s the problem here (A)?

2

On Fri, Aug 26, 2011 at 12:52 PM, jack jones [email protected]
wrote:

def do_something(a as Array)
puts “first array method”
puts a.inspect
end

This is not valid Ruby. Is your problem that you’re getting a syntax
error? Are you giving faux-Ruby to demonstrate what you want? See below.

what’s the problem here (A)?

Ruby is dynamically typed and there is no method overloading. Only the
method name distinguishes it from other methods, and you can’t specify
the
type of an argument in the way you’re suggesting. You can fake method
overloading, by calling other methods:

def foo(x)
foo_for_array(x) if x.is_a? Array
foo_for_hash(x) if x.is_a? Hash
end

private

def foo_for_array(x)
p “foo for array”
p x.inspect
end

def foo_for_hash(x)
p “foo for hash”
p x.inspect
end

But don’t do this. You’d be working against the language, instead of
with
it, and you’d find yourself with more problems later down the line.

Instead of thinking of object types, follow duck typing[1] and think
about
what an object is able to do, instead of what it is — whether an object
is
able to respond to a certain method call. In your particular case, it
makes
no difference what the argument’s class is, because they all respond to
#inspect:

def do_something(arg_of_any_class)
puts arg_of_any_class.inspect
end

There’s no need to try and restrict the type of arg_of_any_class.

[1] Duck typing: Duck typing - Wikipedia

3

Having multiple methods with the same name and choose one based on the
argument’s class is not possible in Ruby.
You cannot even have multiple methods with the same name and different
number of arguments.
Let experts confirm.

Alexey.

P.S. Inside the method you can do

case a.class
when Array
…
when Hash
…
else
…
end

4

On Fri, Aug 26, 2011 at 1:23 PM, Adam P. [email protected]
wrote:

You can fake method overloading, by calling other methods

Slight mistake. I should have instead said: you can fake the type aspect
of
the method overloading you’re expecting. As Alexey pointed out, even the
arity isn’t taken into consideration, and only the name counts.

5

On Fri, Aug 26, 2011 at 2:24 PM, Alexey M.
[email protected] wrote:

Having multiple methods with the same name and choose one based on the
argument’s class is not possible in Ruby.

Not as inbuilt language feature, anyway.

But with OO design, you can fake it, and dispatch method calls
semi-transparently*.

I’ll leave the implementation of this Abomination of All That’s Object
Oriented to the reader, though.

*“semi-transparent” since any implementation of such a thing will
blow up in your face, with hilarious results thanks to the lack of
static typing.

Phillip G.

phgaw.posterous.com | twitter.com/phgaw | gplus.to/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

6

Alexey M. wrote in post #1018634:

P.S. Inside the method you can do

case a.class
when Array
…
when Hash
…
else
…
end

you are wrong

it must be

case a
when Array
…
when Hash
…
else
…
end

7

Alexey M. and Adam P. thank you very much :slight_smile:

8

On Fri, Aug 26, 2011 at 3:02 PM, Hans M. [email protected] wrote:

end

you are wrong

You are both wrong.

it must be

… never done.

That’s the right way dealing with operator overloading. :wink:

–
Phillip G.

phgaw.posterous.com | twitter.com/phgaw | gplus.to/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

9

On Fri, Aug 26, 2011 at 3:51 PM, Alexey M.
[email protected] wrote:

Yes, Hans M. is right, the case operator is more complicated than
i thought.
How would you case a class in this case?

klass = a.class

case klass
when ???
…

A generic solution is

def do_something(*args)
case args.map(&:class)
when [String, String]
puts “Working on two Strings”
when [Integer, String], [Fixnum, String], [Bignum, String]
puts “Working on int and String”
else
raise TypeError, “Dunno what to do with %p” % [args]
end
end

As you can see this soon becomes unwieldy. Which brings us back to

it must be

… never done.

Kind regards

robert

10

On Fri, Aug 26, 2011 at 08:52:48PM +0900, jack jones wrote:

def do_something(a)
do_something(b)
do_something©
do_something(d)

what’s the problem here (A)?

Method overloading is not supported in Ruby.

11

Yes, Hans M. is right, the case operator is more complicated than
i thought.
http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_expressions.html#S5
How would you case a class in this case?

klass = a.class

case klass
when ???
…

I’ve looked up that case uses === for comparison, and not ==, and
in Ruby

String === “str” # => true
(1…3) === 2 # => true
String === String # => false

Somewhat confusing.

Alexey.