From: "Weirich, James" <James.Weirich@...>
Date: 2003-11-19T06:30:44+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata	 about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-435	5dfae.dyn.optonline.net>

David Black (dblack@wobblini.net) wrote:
> Class name checking doesn't ensure needed behavior.  Actually, let me

I share some of David's concerns, but would like to point out that not only
does Class name checking not ensure needed behavior (which is true, but a
small danger in my mind), it overly constrains the software to reject
perfectly good solutions.

Consider the following function.

  def read(io_object)
    fail "Not an IO Object" unless IO === io_object
    io_object.read
  end

This seems like a perfectly reasonable function and we feel safe because
carefully check the "type" (actually Class ancestry) of our parameter.  

Now consider the following usage:

  io = StringIO.new("HI")
  read(io)                # => RuntimeError: Not an IO object

This perfectly reasonable use of read will fail because StringIO does not
enherit from IO, even though it implements IO-like methods.  This is a
shame.  Our "type-checking" has needlessly constrainted our solution.  

That is the danger I see with a lot of the type checking solutions proposed.
Its not that people extend objects, but that they make the software brittle
and less flexible.

Just my two cents.

-- 
-- Jim Weirich / Compuware
-- FWP Capture Services
-- Phone: 859-386-8855