Paul Lutus wrote:
> Edwin Fine wrote:
> 
>> I am perplexed by CSV.open. In IO and File, open returns something that
>> quacks like an IO object. You can then call gets, puts, read, write and
>> so on. The CSV open seems to return an array (or gives you a row at a
>> time).
> 
> / ...
> 
>> I wonder why it was not patterned more closely on IO? Any thoughts?
> 
> This is an experience with which I am becoming familiar. Someone 
> requests a
> solution to a problem. Someone else offers the option of a library to 
> solve
> the problem. Then the original problem fades into the background, 
> replaced
> by discussion of the library's problems.
> 
> This same pattern has repeated itself about four times in the past
> fortnight, in just this one newsgroup.
> /snip/

Ummm, I am not sure exactly how to interpret the above post, but I see 
my name quoted there, so I feel compelled to clarify what I was thinking 
in making my original post. I had just written a small Ruby program that 
would satisfy the OP's stated problem, but using IO/File. While I was 
doing this, more posts appeared, which alerted me to the possibility 
that I would have to cater for newlines in the input., "Oh well", I 
thought, "I'll just replace every use of "IO" with "CSV", and that will 
be that. BZZZ! Wrong! Thank you for playing. I couldn't drop in CSV 
instead of IO? WTF???

This is where my perplexity came in. Matz himself has regularly and 
clearly stated that he designed Ruby along the Principle Of Least 
Surprise (or LOLA, Law of Least Astonishment). Well, I was grievously 
surprised and astonished when CSV#open behaved differently to every open 
I have used in any language. All the other opens that I know of return 
the concept of a handle/object, or some *thing* that can then be 
beseeched to bring forth the contents of the actual I/O "device", one 
element at a time, or all at once. The CSV#open skips this step and goes 
straight from open to bringing forth entities, and thereby breaks 
possible compatibility with IO/File. IMHO, this is inelegant design.

I have written many, many libraries (not in Ruby) and know how important 
it is to present to your users a consistent, clean, orthogonal, 
robust,reliable set of interfaces and implementations. That's why it is 
inadvisable to release a very early version of a library to a large 
audience of end users until it has proven itself in battle, as it were. 
Otherwise, you face the prospect of having to change the interface to be 
less surprising (*and* keep a backward-compatible, deprecated one) and 
re-releasing it to possibly hundreds of users.

The bottom line is, although I am perfectly capable of doing so, I don't 
WANT to reinvent the wheel. I really like reusing good, dependable, 
predictable code. I haven't had time to look at FasterCSV yet, but I 
predict that I will like what I see, because to my mind, from the works 
of his I have seen, the author does his best to embody the "Tao" of Ruby 
(LOLA). (Although you can never accurately describe the Tao of anything, 
I know...)

Well, that's my 2c worth :)

-- 
Posted via http://www.ruby-forum.com/.