James Edward Gray II wrote:
> 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.

I don't like this solution for the long term. It does seem *kludgey* and it seems like we're just 
adding functionality onto the current CSV lib, when you're really not adding onto it, you're 
optimizing it.

> 
> 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.
> 

What would be the drawbacks of maintaining backwards compatibility and cleaning up the library?

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

The only thing I don't like about this personally is now you have two libraries to perform 
essentially the same task. One is slow, the other is fast. So why not just get rid of the slow one?

Perhaps in ruby 1.8.x trees you could offer FastCSV as a separate download for people to use, as 
FastCSV proves itself, perhaps it could be considered as a replacement for CSV in the standard 
library for Ruby 2, especially if it breaks backwards compatibility.

> 
> 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.


Zach