# Re: Duck typing and the Standard Library

**URL:** <https://www.ruby-forum.com/t/re-duck-typing-and-the-standard-library/74609>\
**Category:** Ruby\
**Created:** [November 7, 2006, 10:49am UTC](https://www.ruby-forum.com/t/re-duck-typing-and-the-standard-library/74609 "2006-11-07T10:49:56Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [November 7, 2006, 10:49am UTC](https://www.ruby-forum.com/t/re-duck-typing-and-the-standard-library/74609/1 "2006-11-07T10:49:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kuma](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a587f6/32.png) [@kuma](https://www.ruby-forum.com/u/kuma)\
**Post date:** [November 7, 2006, 10:50am UTC](https://www.ruby-forum.com/t/re-duck-typing-and-the-standard-library/74609/2 "2006-11-07T10:50:00Z")

</div>

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