From: Yukihiro Matsumoto <matz@...>
Date: 2005-08-03T18:58:09+09:00
Subject: Re: [RCR] array or with non-array

Hi,

In message "Re: [RCR] array or with non-array"
    on Wed, 3 Aug 2005 10:40:03 +0900, Eric Mahurin <eric_mahurin@yahoo.com> writes:

|Having the the method take any object that implements the to_s
|is good duck typing, but then we get right back to static
|typing as soon the the built-in methods use the result of to_s
|- they require it to be a string.

I know but it is a matter of cost both efficiency and implementation.
Since current "restriction" covers 99.99% usage of strings, it is
kinda hard to pay cost to implement full polymorphic arguments like
you mentioned.  When MetaRuby comes true, I'm not going to oppose,
perhaps.

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

Convenience is important, sometimes more than pure duck typing.
There still be a room for improvement though.

|I think a primary example where I would really like real
|duck-typing in a built-in would be Regexp#match(str).  This
|requires the arg to be a String.

Again, it's a matter of cost.  For example, full duck typing
Regexp#match likely requires re-implementation of a regular expression
matching engine in Ruby.

							matz.