Hi --

On Sat, 9 Aug 2003, Ben Giddings wrote:

> Testing to see if the "read" method is supported is not really "duck typing",
> in the sense that you're not really checking to see if it's a duck.  Just
> because the object implements a certain method doesn't mean that that method
> does what you expect.

No specific thing you or I do in a program is "duck typing".  As Dave
Thomas explained, "duck typing" is a way of thinking about programming
in Ruby.  It's more a matter of "Ruby exhibits the 'duck typing'
principle," than a matter of "You can do duck typing in Ruby."

(I know this sound perhaps ridiculous pedantic.  But if this term's
connotations get redefined, we'll just have to come up with another term
to mean what Dave originally meant by "duck typing," and that seems like
extra work :-)

[...]

> As for the subject of why it is useful to implement a set of methods rather
> than just the one you care about, consider a function like:
>
> def dumpContents(obj)
>   if obj.respond_to? :write
>     obj.write(data)
>     obj.flush if obj.respond_to? :flush
>     obj.close if obj.respond_to? :close
>   elsif ...
>   end
> end
>
> I think it would be much more clear if you could simply say:
>
> def dumpContents(obj)
>   if obj.implements_interface? :WriteableIO
>     obj.write(data)
>     obj.flush
>     obj.close
>   elsif ...
>   end
> end

You can certainly do something quite similar to that:

  module WriteableIO
  # ...
  end

  obj.extend(WriteableIO)  # or include in class, or whatever

  if obj.is_a?(WriteableIO)
  # ...
  end

but you *still* are playing in Ruby's ballpark, which means that,
theoretically, obj could also have been extended by another module
which overrides WriteableIO's methods, or have had one of those
methods overridden, and so on.

This is, I think, why many Ruby programmers are also fanatical unit
testers.


David

-- 
David Alan Black
home: dblack / superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav