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.

> 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.

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

-- 
                   David A. Black | dblack / wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org