From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-04T04:21:15+09:00
Subject: Re: [RCR] array or with non-array

--- "David A. Black" <dblack@wobblini.net> wrote:

> Hi --
> 
> On Thu, 4 Aug 2005, Eric Mahurin wrote:
> 
> >> |But, this wasn't really what my #1 above was about.  It
> was
> >> |about overloaded methods where the functionality is
> >> determined
> >> |by looking at the type of the arguments.  One example
> would
> >> be
> >> |String#[arg]:
> >> |
> >> |str[fixnum] => fixnum or nil
> >> |str[range] => new_str or nil
> >> |str[regexp] => new_str or nil
> >> |str[other_str] => new_str or nil
> >> |
> >> |All of these behave very different.  The way you figure
> out
> >> |what to do is based on type - which goes against the
> >> |duck-typing philosophy.  I think the only advantage of
> >> |combining all of these functions into one method is
> >> |convenience.  But, by doing so you loose the ability to
> >> handle
> >> |more general duck-typed/polymorphic arguments.
> 
> class != type.  Type is at the heart of duck-typing; class
> isn't :-)


Huh?  Where do you get that?  Duck-typing is about not caring
about what the type/class the object is.  Duck-typing in the
purest sense is calling the methods of the arguments without
regard to what the class of the object is.

In the above, the functionality is clearly affected by the
class.  If you wrote the single arg String#[] above you'd have
something like this:

def [](i)
    if Fixnum===i
        # retrieve character at index i
    elsif Range===i
        # retrieve slice designated by the Range i
    elsif Regexp===i
        # retrieve slice found by the Regexp i
    elsif String===i
        # retrieve slice that is the same as String i
    else
        raise
    end
end

That is far from duck-typing.  This very much cares about the
type/class of the argument.  It both restricts the class and
makes decisions about what functionality to have based on that
type.  You could use respond_to? instead of klass=== to help,
but that would like just introduce ambiguities about what
functional branch to take - you'd have to favor one case over
another.  Implementation-wise, I don't have a problem with
choosing how to operate based on class, but this decision
should not affect functionality - only performance.



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs