Am 16 Nov 2007 um 23:07 hat Nobuyoshi Nakada geschrieben:
> At Fri, 16 Nov 2007 18:13:36 +0900,
> Dirk Traulsen wrote in [ruby-core:13594]:

> > Iconv needs to be changed anyway. So, is it better to be consistent
> > or not?
> 
> Could you tell the reason why it needs?

Because it is a lot easier to learn/remember the methods if they behave 
like expected and return what the documentation says, 
and because programming is all about logic and inconsistency isn't 
logical.  


> > Iconv#iconv should return an array like Iconv.iconv and like it was
> > documented.
>  
> It breaks backward compatibility, and it doesn't make much
> sense because they are not convertible.

Today it returns a string,while the documentation describes a complete 
different method which returns an array. It is already broken! 

It has to be fixed. You have to change Iconv anyway.
Now, 1.9.1/2.0 will bring some drastic changes. People will have to 
look at the changes and code will break. It is the perfect moment to 
correct Iconv!
 
I see 2 good solutions:

Solution A. - Change the erroneous instance method:

Iconv.iconv => Array                        (established)
Iconv#iconv => Array                        (corrected)
Iconv.conv => String (=Array.join)          (established)
[Iconv#conv => String (=Array.join)          (optional new method)]


Solution B. - Change the class method and add new to_a-methods:

Iconv.iconv => String (=Array.join)         (make it like Iconv#iconv)
Iconv.conv  => String (=Array.join)         (established)
Iconv#iconv => String (=Array.join)         (today)
+ 
Iconv.to_a => Array                         (new method)
Iconv#to_a => Array                         (new method)

I would prefer solution B, which has the additional plus of 'speaking' 
method names:
(i)conv:  convert one string to another string
to_a:    make an array of lines.

Dirk