From: James Edward Gray II <james@...>
Date: 2005-10-31T07:58:18+09:00
Subject: Planning FasterCSV (was Re: csv.rb a start on refactoring.)

I've decided to create a FasterCSV library, based on the code we  
worked out in this thread.  I'm playing with some different options  
and would like to hear opinions.  Would you rather I:

1.  Add a CSV::fast_parse() to the current CSV library in an attempt  
to dodge compatibility issues.
2.  Try to make FasterCSV API compatible with CSV, so your just  
change your require statement if you want to switch over.
3.  Make FasterCSV an all new library for parsing CSV.  This might  
give us some fun options, like a "header" option to treat the first  
as headers and then allow you to access fields in the rows by name.

One feels very kludgy to me.  It smells like we don't trust the  
solution.  Maybe we don't yet, but if we get it covered with tests  
and keep throwing edge cases at it, I don't see any reason we can't  
get it to trusted status.

Two seems the nicest for backward compatibility, but I'm not sure how  
far we would go.  Do I also need to support all the Reader, IOReader,  
StringReader, Writer, BasicWriter classes?  I guess my gut feeling is  
that I want to get away from all this complexity and back to lean,  
functional, and fast.

Three means freedom to build whatever we decide is truly needed.

Here's another question, probably for Matz:  Any chance of getting  
any of these into the Standard Library?  If so, which would you  
prefer for that?

I guess I figure that if I'm just going to be offering a gem anyway,  
there isn't much concern over a new API.

Food for thought.  Tell me what you think.

James Edward Gray II