In Java, you could write the following code:
public void foo(int x)
{ /* do something*/ }
public void foo(String x)
{ /* do something*/ }
int x1
String x2
foo(x1)
foo(x2)
The 2nd to last line would call the first foo and the last line would
call the 2nd foo.
Is there a way to do this in Ruby? I am aware of method(*args) and
case…when but I think Java’s version is cleaner and more readable. I
also know that variables in Ruby are dynamically typed, the method that
is called should be based on the most recent type of the variable being
passed.
I don’t want to do this:
def foo(arg)
if arg.type_of? String
# do something
elsif arg.type_of? Numeric #do something
else
raise args error
end
end
foo(x1)
I don’t want to do this:
def foo(arg)
if arg.type_of? String
do something
elsif arg.type_of? Numeric #do something
else
raise args error
end
end
It’s not just a matter of dynamic vs. static typing. In Ruby, an
object’s class (i.e., what it’s an instance of, what it reports when
you call #class on it) is not necessarily representative of the type
of the object (i.e., the capabilities of the object, the methods it
knows, at any given point in its life).
Over the years there have been various mechanisms proposed (and in
some cases written as add-on libraries) that check the class or
class/module ancestry of objects, and either dispatch differentially
based on those criteria or raise errors if the criteria aren’t met.
These systems all suffer from two major problems:
they don’t work, because they don’t account for the possibility
of an object’s having behavior that doesn’t derive from its class
of origin;
by setting up a kind of phantom “type”-checking (i.e., class-
checking, in a language where type != class), they tend to
discourage thinking about other ways in which Ruby objects can
be engineered, and some of the freedoms available to those
objects.
There have also been some interesting attempts to define and profile
the type of Ruby objects. It’s difficult: it involves consideration
of, at least, the methods the object responds to (which can change),
how those methods behave, and any publicly changeable state in the
object. I don’t think any of these attempts has been completed (and
they’ve been attempted by some very good programmers). Ultimately,
“type” in Ruby is a circularity: an object’s type is “the type which
objects that are just like this object have”, or something like that.
Type is elusive, but that rarely matters.
Java’s (and C++'s) kind of method overloading just isn’t do-able in
Ruby. Generally, if you have a method that can take either a String or a
Numeric argument, then you create two methods, one that takes a String
argument and another for the Numeric argument.
Switching on the class of an argument is also regarded with suspicion
but is acceptable in some cases. Search for “duck typing” in the Pickaxe
or in the archives of this mailing list for exhaustive discussions.
I don’t want to do this:
def foo(arg)
if arg.type_of? String
# do something
elsif arg.type_of? Numeric #do something
else
raise args error
end
end
That’s the only way to do it.
You’d be better served if you considered code like that a smell. If
you’ve got a method whose functionality varies vastly based on the
type of its arguments, then they probably deserve to be separate
methods, with more descriptive names.
Is there a way to do this in Ruby? I am aware of method(*args) and
case…when but I think Java’s version is cleaner and more readable. I
also know that variables in Ruby are dynamically typed, the method that
is called should be based on the most recent type of the variable being
passed.
If you want different types of objects to perform different behavior
for the same method call, you use polymorphism. What OP wants to do
is essentially a design pattern for providing polymorphism
capabilities to a language that doesn’t have them built in.