Method overloading

I

imodev

Hi all,

I think I guess the answer to this question, but I'd like to know if I'm
wrong or I'm missing something.

I wanna ask you about method overloading. You can overload methods based on
the number of parameters but... what about overloading based on parameter's
classes? Something like (in C++):

int test(int a)
int test(char* a)

Is there any way or must I write some code like: if (a.class == 'class')
then...?

I hope I explained right ;-)

Thank you.
 
R

Robert Klemme

Hi all,

I think I guess the answer to this question, but I'd like to know if I'm
wrong or I'm missing something.

I wanna ask you about method overloading. You can overload methods based on
the number of parameters but... what about overloading based on parameter's
classes? Something like (in C++):

int test(int a)
int test(char* a)

Is there any way or must I write some code like: if (a.class == 'class')
then...?

It's not built into the language, but there are some resources (text and
code) out there:
http://www.rubygarden.org/ruby?MethodOverloading

For more questions about C++ like Ruby:
http://www.rubygarden.org/ruby?RubyFromCpp
I hope I explained right ;-)

Perfectly.

Kind regards

robert
 
D

Dave Burt

... what about overloading based on parameter's
classes? Something like (in C++):

int test(int a)
int test(char* a)

Is there any way or must I write some code like: if (a.class == 'class')
then...?

Yes. The class method returns a Class object. So you can compare:
a.class <= Integer
to check if a is an Integer or any subclass of Integer.

Better, you can use the kind_of? method:
a.kind_of?(Integer)
which is more obvious.

But for this situation, a case statement is probably best:

def test(a)
case a
when Integer
# ...
when String
# ...
else
raise ArgumentError, "test(a): parameter must be Integer or String",
caller
end
end
 
R

Robert Klemme

Dave Burt said:
Yes. The class method returns a Class object. So you can compare:
a.class <= Integer
to check if a is an Integer or any subclass of Integer.

Better, you can use the kind_of? method:
a.kind_of?(Integer)
which is more obvious.

And then there is the third idiom:

Integer === a

which btw nicely integrates in case statements as you show below:
But for this situation, a case statement is probably best:

def test(a)
case a
when Integer
# ...
when String
# ...
else
raise ArgumentError, "test(a): parameter must be Integer or String",
caller
end
end

Btw: there's a gotcha with the idiom on the wiki:

def fred(*args)
case args.collect { |a| a.type}
when [Float, Fixnum, String]
f, i, s = args
# ...


This will not use Class#=== i.e. match only if the arguments' types match
identical (instead of sub classes matching with superclasses for all the
three idioms listed above).

Kind regards

robert
 
D

Dave Burt

Robert Klemme said:
And then there is the third idiom:

Integer === a

...

Btw: there's a gotcha with the idiom on the wiki:

def fred(*args)
case args.collect { |a| a.type}
when [Float, Fixnum, String]
f, i, s = args
# ...


This will not use Class#=== i.e. match only if the arguments' types match
identical (instead of sub classes matching with superclasses for all the
three idioms listed above).


My omissions were for simplicity; thanks for expanding, Robert.

Further, just after posting this, I read Tim Bates on duck typing
[ruby-talk:100516], and was convicted.

A well-designed program will usually not need to do that kind of thing.
Method overloading like that is a very static-typing thing to do. The Ruby
Way often obviates the need for such checks.
 
R

Robert Klemme

Dave Burt said:
Robert Klemme said:
And then there is the third idiom:

Integer === a

...

Btw: there's a gotcha with the idiom on the wiki:

def fred(*args)
case args.collect { |a| a.type}
when [Float, Fixnum, String]
f, i, s = args
# ...


This will not use Class#=== i.e. match only if the arguments' types match
identical (instead of sub classes matching with superclasses for all the
three idioms listed above).


My omissions were for simplicity; thanks for expanding, Robert.

Further, just after posting this, I read Tim Bates on duck typing
[ruby-talk:100516], and was convicted.

A well-designed program will usually not need to do that kind of thing.
Method overloading like that is a very static-typing thing to do. The Ruby
Way often obviates the need for such checks.

Yeah, true. And *if* different argument lists lead to different behavior,
then it might be better to use different method names anyway.

Regards

robert
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top