I have been digging a bit to find what people consider loose ends in Text::CSV_XS, and tried to summarize that (in no particular order) in the new TODO list. Here TODO gives no guarantee that it will be done, nor on any implementation or API that it might suggest, it is there now just so I/we do not forget to think about these issues.
I'd like to get thoughts/feedback/suggestions about items on this list, and how valuable you consider adding these features to a modules so heavily used by other applications.
jZed asked me to also post to this to the dbi-users list, cause many DBI users (have to) deal with CSV data, which I already did. So start shooting ...
New extensions ought to be clear and concise in reporting what error occurred where and why, and possibly also tell a remedy to the problem. error_diag is a (very) good start, but there is more work to be done here.
Basic calls should croak or warn on illegal parameters. Errors should be documented.
Future extensions might include extending the meta_info (), is_quoted (), and is_binary () to accept setting these flags for fields, so you can specify which fields are quoted in the combine ()/string () combination.
$csv->meta_info (0, 1, 1, 3, 0, 0); $csv->is_quoted (3, 1);
Requests for adding means (methods) that combine combine () and string () in a single call will not be honored. Likewise for parse () and fields (). Given the trouble with embedded newlines, Using getline () and print () instead is the preferred way to go.
The hard-coding of characters and character ranges makes this module
unusable on EBCDIC system. Using some #ifdef structure could enable
these again without loosing speed. Testing would be the hard part.
The most current state is available on the public GIT repo.