[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Duck typing and the Standard Library
From:       dblack () wobblini ! net
Date:       2006-10-31 12:10:51
Message-ID: Pine.LNX.4.64.0610310700160.19124 () rubypal ! com
[Download RAW message or body]

Hi --

On Tue, 31 Oct 2006, mikeharder@gmail.com wrote:

>
> Robert Klemme wrote:
>> On 31.10.2006 10:19, mikeharder@gmail.com wrote:
>>> I'm new to Ruby, so please excuse any ignorance on my part.  I read the
>>> following article about Ruby and "duck typing":
>>>
>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511
>>>
>>> I got the impression that duck typing is the "right" way to do things
>>> in Ruby.  However, the Ruby Standard Library itself doesn't seem to use
>>> duck typing.  Consider the following example:
>>>
>>> irb(main):001:0> require 'set'
>>> => true
>>> irb(main):002:0> s = Set.new
>>> => #<Set: {}>
>>> irb(main):003:0> s.superset? 0
>>> ArgumentError: value must be a set
>>>
>>> It seems like the "superset?" method explicitly checks that its
>>> parameter is a set.  This is approach #1 in the "duck typing" article
>>> above, which the article claims is not "the Ruby way".
>>>
>>> So, what gives? If it's wrong to "try to make Ruby do Static Typing"
>>> (as the article says), then why does the Ruby Standard Library do it?
>>
>> It is just giving you a nicer error message.  Otherwise, this might happen:
>>
>> irb(main):003:0> def foo(s) s=s.to_set end
>> => nil
>> irb(main):004:0> foo []
>> => #<Set: {}>
>> irb(main):005:0> foo Set.new
>> => #<Set: {}>
>> irb(main):006:0> foo 0
>> NoMethodError: undefined method `to_set' for 0:Fixnum
>>          from (irb):3:in `foo'
>>          from (irb):6
>>
>> Note that there must be an exception of some kind if the parameter is
>> inappropriate.  And no, this is not static typing.
>>
>> Kind regards
>>
>> 	robert
>
> Yes, there must be an exception of some kind if the parameter is
> inappropriate.  The question is whether to explicitly check the type of
> the parameter and throw a nicer exception, or to explicitly *not* check
> the type of the parameter and let the exception happen where it may
> (i.e. when a needed method does not exist).
>
> Arguments can be made for both sides, but which is considered the "best
> practice" for Ruby development?  The Ruby Standard Library suggests it
> is the former, but the article I referenced above suggests it is the
> latter.

The way I've always looked at it is that the Ruby core and standard
library do a certain number of things along these lines that are
necessary for bootstrapping the basic classes into existence and
dealing with their relations, but that aren't necessarily what you'd
do normally when using those classes.  You get a lot more "type"
errors (most of which are actually class errors) from the built-ins
than from most other code.

The main disadvantages of testing for class/module ancestry are:

   1. it doesn't actually guarantee an object's behavior;
   2. it discourages thinking about more flexible ways of programming.

I think that in the case of some of the standard and core classes,
these concerns don't loom as large as they might in our programs.  At
the same time, there's no particular reason for those classes *not* to
be more duck-type oriented, if that can be done without introducing
any problems.


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

[prev in list] [next in list] [prev in thread] [next in thread]