Re^2: Comparison of the parsing features of CSV (and xSV) modules

You missed a few features of Text::xSV

It wasn't my intention to make a full comparison of the features, only of the CSV parsing. Like Text::xSV, AnyData and the DBDs also have many options for handling the resulting data structures, it would take a much lengthier meditation to compare all of those.

Adding a few features shouldn't be difficult.

Those features may or may not be worthwhile in Text::xSV. I didn't intend the minus signs in the chart to necessarily indicate something the modules should support. Then again if Tilly does add the user-defined features, I can use Text::xSV as a backend for DBD::AnyData so that there would be a DBI/SQL interface to his excellent module.

Comment on Re^2: Comparison of the parsing features of CSV (and xSV) modules

Replies are listed 'Best First'.
Re^3: Comparison of the parsing features of CSV (and xSV) modules by tilly (Archbishop) on Jun 18, 2004 at 02:17 UTC
The problem is not adding the features, it is figuring out the API for offering them, and seeing the need. Which of the above user-defined features does DBD::AnyData need? All of them? Some? We probably should offline a discussion of how to provide them in a sane manner. Some are already present in some form. For instance Text::xSV offers the ability to pre-filter input as it comes in. There is nothing to stop such a filter from saying, "These characters are not allowed." That won't work for eliminating embedded tabs in tab-delimited data. But it would for NUL characters. And if you want to disallow tabs embedded in a tab-delimited file, you could just wrap Text::xSV with the necessary validation logic. Also as dragonchild points out, it reads based on $/ which can effectively allow you to change the record separator. Furthermore because I got tired of bug reports about invalid csv files, by default Text::xSV will treat either \n or \r\n as a newline, so files produced on Windows can be read on Unix and vice versa. Some of the other missing features can't presently be worked around. For me the barrier isn't adding them if I thought people would use them, it is figuring out what a reasonable API should be.	[reply]
Re^4: Comparison of the parsing features of CSV (and xSV) modules by jZed (Prior) on Jun 18, 2004 at 02:53 UTC
T> Which of the above user-defined features does DBD::AnyData need? All of them? Some? We probably should offline a discussion of how to provide them in a sane manner. JZ> I'll think it over and msg you. I'm not sure it's worth your trouble if you don't have other uses for them. As I said, the minuses in the chart don't necessarily indicate a lack. Your module covers most of the formats people need, the other modules fill in the gaps for some odd formats that cover the edge cases. T> Some are already present in some form. JZ> I'll take a closer look and revise the chart. T> because I got tired of bug reports about invalid csv files, by default Text::xSV will treat either \n or \r\n as a newline, so files produced on Windows can be read on Unix and vice versa. JZ> I hear you. :-)	[reply]