From: Devin Mullins <twifkak@...>
Date: 2005-08-03T19:09:52+09:00
Subject: Re: [RCR] array or with non-array

Eric Mahurin wrote:

>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.
>
Uhh... erh?
1. What methods do you think Regexp#match (or IO#write) calls on a 
String object to extract the data out of it? What would you mock to make 
your object quack like a String, for Regexp#match to be able to print it 
to the screen? What would you have the #each method return?
2. What added flexibility would you get out of having to_str (not to_s) 
return a duck rather than a String? Specifically, what flexibility would 
you get that is not afforded by the ability to subclass String?

That said, I realize that not every core method is IO#write. :)

>One example would be
>String#[arg]:
>
>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.
>
True. But...

>  I think the only advantage of
>combining all of these functions into one method is
>convenience.
>
Convenience is very important. It's why Rubyists do:
array.each {|i| puts i}
but Javaers don't:
array.each(new Function() {
  public void call(Object obj) {
    System.out.println(obj);
  }
}
(with a Function interface definition somewhere, and an each method 
definition on a subclass of ArrayList somewhere else).

Devin