Re: Duck typing and the Standard Library

Ruby
1

Why is it bad practice to check the type of a value at runtime? I’m new
to Ruby, but I thought that I had read that it is dynamically, strongly
typed, meaning that variables do not have types but values do. I would
think that it would be common to check types at run time.

I would think that checking types of values would be part and parcel of
good object-oriented programming. Doesn’t OO insist that classes are
more than the sum of their methods? Does duck-typing contradict this?
Does it expect us to treat the following classes as
assignment-compatible?

class DatabaseConnection
def open()
#…
end

def close()
#…
end

Returns true if the connection has been opened.

def check()
# …
end
end

class BankAccount
def open()
#…
end

def close()
#…
end

Returns a Check object with a new check number.

Fails if open has not been called.

def check()
#…
end
end

The contracts of these classes are totally different.

2

Hi –

On Wed, 1 Nov 2006, Hartin, Brian wrote:

Why is it bad practice to check the type of a value at runtime? I’m new
to Ruby, but I thought that I had read that it is dynamically, strongly
typed, meaning that variables do not have types but values do. I would
think that it would be common to check types at run time.

It depends what you mean by checking type. In Ruby, class and type
are two different concepts: an object’s class is what you get when you
say: obj.class, while its type is a sort of after-the-fact
characterization of its capabilities.

Every Ruby object can have its own runtime profile (type). That has
certain implications. Checking an object’s class is often a good
indicator, but never a guarantee, of the object’s behavior. At a more
fine-grained level, you can check to see whether an object is aware of
a given method, using respond_to?, before you call the method. This
comes closer to checking the object’s type.

end

Fails if open has not been called.

def check()
#…
end
end

The contracts of these classes are totally different.

The idea(l) of duck typing would be that you simply send a message to
an object, and let the object handle the message. The kind of
synonymy you’re demonstrating is certainly something you have to be
aware of, though. In practical terms, however, the likelihood of
there being a problem is equal to (or less than) the likelihood of
someone’s doing this:

dbc = BankAccount.new

when they meant to do this:

dbc = DatabaseConnection.new

which is pretty slim. And if that can happen, then this can happen:

dbc = DatabaseConnection.new
def dbc.close
dbc.command(“drop database…”)
end

etc. In other words, the fact that an object reports its class as
DatabaseConnection doesn’t guarantee the result of calling its
methods, either.

David