On 28-08-2008, at 10:50, Eero Saynatkari wrote:

> Issue #512 has been updated by Eero Saynatkari.
>
>
> Nakada said: "It's an implementation detail"
>
> I would disagree it is an implementation detail for the reason that  
> Lars posted an example about and the inverse of the example is also  
> true, if someone expects to have #to_ary called but it is not. I  
> think perhaps we see the problem from different aspects. Am I  
> correct in assuming that your point is that String#% always expects  
> an Array argument (whether true Array or #to_ary)?
>
> I suppose a third option would be to specify that the more specific  
> conversion is attempted first (e.g. #to_s(tr) for %s, #to_i(nt) for  
> %c etc.) and if it does not exist, #to_ary is attempted. To me it is  
> more logical to never convert to Array when only one value is asked  
> for to begin with.
>
> My preference is only calling #to_ary when multiple substitutions  
> exist, but it does not really matter which option is chosen. I do  
> think it must be specified to behave one way or the other, even if  
> it is the current implementation.
>
> (In my opinion, any use of #to_ary, #to_int, etc. or even #to_a,  
> #to_i can never be an implementation detail because it affects user  
> code.)

IMHO, String#% should always expect an array as the right part. Having  
it to expect an object and calling #to_ary on that object is not  
desirable and ambiguous. It might also lead to some sort (speculating  
here) of performance penalty since it must check the number of needed  
arguments before checking if the right part should be array or not. I  
would expect:

"%d" % [1]

to work, and

"%d" % 1

to fail with ArgumentError or something like that. I think (again,  
IMHO) that this might lead to a simpler and more efficient  
implementation.
regards,
-- 
Rolando Abarca M.