Re: Package Proposal: Text_TSV

On Monday, Jul 14, 2003, at 09:26 US/Central, George Schlossnagle wrote:

On Monday, July 14, 2003, at 10:21 AM, Paul M Jones wrote:

On Monday, Jul 14, 2003, at 05:17 US/Central, Martin Jansen wrote:

On Sun Jul 13, 2003 at 07:5235PM +0200, Tomas V.V.Cox wrote:

I love the well presented class, but I guess that there is already this functionality in PEAR and missing features should be implemented there. At least the points you mention in your page can be easily added. I'm -1.

Agreed. Paul: What do you think about merging string support into File_CSV?

I was hoping I could get away with just the Text_TSV class (as I am lazy and want to do the least work possible ;-), but I agree that it'd be best to merge the code in some fashion. My only argument against doing so with File_CSV as it stands is that the name "File_" implies the class is for file-work, not text-work in general. I'd like to suggest the following:

    (1) Merge the parsing code in File_CSV with the contents
    of Text_TSV to create a Text_CSV class that parses CSV text
    blocks into their component parts.

    (2) Remove the parsing code from File_CSV entirely so that
    it only reads lines from the .csv file, then passes them off
    to Text_CSV for parsing and returns those results.

so besides fopen()/fgets()/fclose(), what would File_CSV natively do?

Hmm ... well, not a lot, I guess. The parsing code in File_CSV is pretty thoroughly integrated with the file-reading code. They look to be heavily dependent on each other -- and rightfully so, since the class has to keep track of where it is in the file so it can start reading on the proper next-line.

I'm -1 for creating a useless shell of File_CSV, and -1 for moving without making it a shell, for bc reasons.

Agreed it would have to keep backwards compatibility for the suggestion to make sense, and agreed that if the Text_CSV idea is approved (not looking good at this point ;-) File_CSV would *have* to become a shell to separate the parsing from the reading. (Which brings us back to the "integration and dependence" point I made above, that the parsing is required to be integrated with the file-reading so that the class can keep track of its place in the CSV file so it can read the next line). That, in turn, brings us back to my original reason for proposing Text_TSV: sometimes you don't need to parse a file, you need to parse form input or a database field (well, I do anyway ;-). The only PEAR-based option for parsing form input in CSV/TSV format, using the extant File_CSV class, is to write the source text to a temp file, then parse it with File_CSV, then delete the temp file (which seems kind of roundabout to me).

Not sure if that adds up to -2 or not.

I think it's -3: you, Martin, and Tomas. :-( -- pmj