From: James Edward Gray II <james@...>
Date: 2005-11-01T02:21:28+09:00
Subject: Re: csv.rb a start on refactoring.

On Oct 29, 2005, at 12:11 PM, Ara.T.Howard wrote:

> it may or may not be tricky to get these failing cases working though:

I'm building a test suite for the new library, including all the edge  
cases you posted.  Can you tell me what exactly you meant to check  
with the following test:

   [
     %( \r,"\r" ),
     [nil,"\r"]
   ],

You are strip()ing those before testing them, so the method is  
actually fed %Q{,"\r"}.  The first \r is trimmed, as you can see.   
With that input, we all agree on your answer.

If you meant to leave the \r in, it gets more complicated.  My code  
says that's ["\r", "\r"].  CSV says that's [].  I guess it is  
considering the \r a line end.  I have a hard time convincing myself  
that behavior is correct though.

The way I read the RCF, the only valid line ending in the format is  
\015\012.  It also says that line endings must be enclosed in double  
quotes.  That leaves me feeling that either a field containing \r  
becomes "\r", just as my code says, because it's not a line ending,  
or it's malformed CSV.  We still need a preferred way to handle it  
though.

I'm inclined to ignore the RCF here and call Ruby's platform dynamic  
\n a line ending.  I'm also inclined to say that means \r isn't (on  
all platforms where \n != \015, which includes Windows and Unix) and  
my code is correct, it's a "\r" field.

Object now if you think I'm crazy...  ;)

James Edward Gray II