On Jun 4, 2006, at 7:55 PM, NAKAMURA, Hiroshi wrote:

> I can understand your frustration about this point.  When I wrote  
> csv.rb
> at first, I thought all csv users would do the following when I define
> reader style.
>
>   CSV.open("filename.csv", "r") do |reader|
>     reader.each do |row|
>       ...do something...
>     end
>   end
>
> Why don't we just write like this;
>
>   CSV.open("filename.csv", "r") do |row|
>     ...do something...
>   end

That's why we have foreach().  Better to use that and gain all the  
familiarity of Ruby programmers who are use to things working that way.

> I know you are considering that IO-ish methods are important.  But I
> don't think CSV object should handle IO methods like fcntl, fileno,
> seek, tell, tty?, and so on.  Would you please tell me typical and
> pragmatic examples of reader style, except 'each'?

If people only did what I could think of, programming would be very  
boring.  ;)  It took me five or ten minutes to make all those methods  
available and now they are there if someone needs them.

I can tell you that it has already come in handy.  I got a bug report  
that the line numbers in errors were off, because CSV allows embedded  
\n characters in fields.  To fix it, I overrode IO's lineno() method  
with correct behavior.  This seems very natural and the added bonus  
is that you can now get a CSV aware line number.

>> I'm confused about why CSV does this, since it offers the foreach()
>> method, which normally fills this role.
>
> foreach and readlines are added recently from IO.  Now I think it  
> was a
> bad choice though...

That makes me sad to hear.  foreach() is easily my most used method  
with CSV and FasterCSV.  I like readlines() too.

I still can't think of any good reason not to just follow Ruby's  
interface as much as is possible and natural.  To do anything else  
forces programmers to adapt their expectations for no reason I can  
understand.

>> *  I always have to think, "Now do I want the *_line() method or the
>> *_row() method here..."
>
> Users don't need to use *_line and *_row methods I think.  When do you
> use generate_line?

I'm pretty sure we want to have our CSV library support data not in  
files.  Am I missing something?  Is there a better way to get a CSV  
string with your library?

>> *  Most methods take a field separator and a row separator, but
>> foreach() and readlines() only take the row separator.
>
> See IO.foreach and IO.readlines.

That's comparing apples and oranges.  IO.foreach() doesn't need to be  
aware of fields, but CSV.foreach() does.  IO.open() doesn't support a  
field separator or a row separator, but your CSV.open() does because  
it is needed.

>> *  I have to set a field separator when I really just want to set  
>> a row
>> separator.
>
> csv.rb in svn repository supports pseudo-keyword-like-method-argument
> style.  I'll merge it ruby's csv repository before the next release.
> http://dev.ctor.org/csv/browser/trunk/lib/csv.rb
>
> # I defined keywords :fs and :rs but it should be :col_sep  
> and :row_sep
> # in conformity with faster_csv.

:fs and :rs are fine with me.  It's consistent with your interface.

>> Here's a selection of some features from my CHANGELOG that I am not
>> aware of in CSV:
>
> Thanks.  I'll look into this.  I hope those features are pluggable  
> into
> csv.rb and other modules like DBI, spreadsheet related things, HTML
> table formatters, etc.  I think some of these features are table
> specific, not CSV.

This leads me naturally to the question:  is there any good reason to  
reinvent FasterCSV, when we could just use FasterCSV?  ;)

James Edward Gray II