Re: Iconv#iconv returning wrong object

Am 16 Nov 2007 um 17:07 hat Nobuyoshi Nakada geschrieben:
> At Fri, 16 Nov 2007 16:17:04 +0900,
> Dirk Traulsen wrote in [ruby-core:13589]:
> > > Iconv::iconv and Iconv#iconv refer same instance method.  
> > 
> > Definitely not!
> > 
> > > You seem to be just confused by the notation.
> > 
> > Definitely not me!
> 
> Sorry, confused was me.
 
OK.
So even the best have bad moments :).

> > And it is extremely inconsistent when the CLASS METHOD Iconv.iconv
> > returns an array, while the INSTANCE METHOD Iconv#iconv returns a 
> > string.
> 
> The former has two mandatory arguments for charset names, while
> the latter doesn't.  They have different interfaces.
(..) 
> RDoc was wrong.  

I know. But independent of the wrong interface in RDoc, wouldn't it be 
better to have Iconv return consistent objects?

Iconv.iconv => Array
Iconv.conv => String (=Array.join)

Iconv#iconv => Array
Iconv#conv => String (=Array.join)

This would be the Ruby way of the least surprise.
The class methods already exist today and I would propose, that 
1. 
Iconv#iconv should return an array like Iconv.iconv and like it was 
documented. (I would like to follow the 'spirit' of the documentation 
here, which calls the method a shorthand of Iconv.open and collect and 
such returning an array, even if it makes the error to give a wrong 
interface, which needs to be corrected anyway.)
2.
Iconv#conv should be introduced as a new instance method of Iconv, 
which returns a string using Array.join like the class method 
Iconv.conv does today. (Iconv#conv would return consistently what 
Iconv#iconv is now returning against the documentation and logic.)

What is the opinion on the list?
Iconv needs to be changed anyway. So, is it better to be consistent or 
not?
Or should I better start a new thread, which explicitely asks for 
opinions?

Dirk

(Wow, there are really a lot of iconv's in this thread!)