On May 27, 2006, at 11:20 AM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: FasterCSV RCR?"
>     on Sat, 27 May 2006 14:31:50 +0900, Hal Fulton  
> <hal9000 / hypermetrics.com> writes:
>
> |I'd suggest changing the name to CSV. And possibly defaulting to
> |compat-mode or perhaps issuing a warning if it's detected that
> |the user is trying to use the Old Library.
>
> I agree.  I don't want to have two independent CSV readers in the
> distribution.  It's OK that compatible mode is slow, or gives
> obsoletion warning.  But we have to discuss about when it should
> happen - during 1.8.x or for 1.9.

Alright, I've thought a lot about this and there is really one big  
issue here:  CSV and FasterCSV are not 100% compatible.  If it was  
just the method arguments, we could get pretty close to perfect, but  
CSV does some odd things like confuse open() with foreach() that I  
chose to avoid in FasterCSV.  Because of that, I can't always be sure  
what to do when user code calls a given method.

That leaves two options, in my opinion:

1.  CSV's compatibility mode handles most of the issues very well and  
I'm pretty sure I can remove most of the speed penalty.  If we go  
with that, we have a pretty workable solution right now with one big  
gotcha:  you can require a file named csv.rb and use CSV just fine,  
but the good stuff will actually be hiding under FasterCSV (in the  
same file).  I have to keep them separate, because of the  
compatibility issues mentioned above.  This, to me, is the only sane  
way to go if we want to target the 1.8.x branch.  It would still  
break some software, if they use the unusual features of CSV, but I  
suspect this is quite rare.
2.  We could drop compatibility and rename FasterCSV to CSV.  This  
way people get all the good stuff where they expect it.  However,  
this would break a lot of CSV software (most of it, in fact), so it  
only seems reasonable when targeting 1.9.x and up.

My thought is that the second option seems preferable.  If we train  
people to use FasterCSV, then we just have to switch them again down  
the road if we want to revert to CSV.  We don't really gain many big  
advantages for the switch either (speed, if I can eliminate the  
penalty, but not header parsing or the other good FasterCSV  
features).  That doesn't sound like it's worth breaking software over.

In summary, I recommending targeting 1.9.x with no compatibility mode  
and renaming FasterCSV to CSV.  Am I making sense here?

James Edward Gray II