in reply to Text::CSV_XS - proposed new interface

Instead of reworking Text::CSV_XS, what about providing an XS solution to Text::xSV. I'm pretty sure tilly wouldn't mind the help ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: Text::CSV_XS - proposed new interface

Replies are listed 'Best First'.
Re^2: Text::CSV_XS - proposed new interface
by jZed (Prior) on Dec 15, 2004 at 19:18 UTC
    Because Text::CSV_XS has been on CPAN 6 years and has many users. And because one of the most useful features that Text::xSV has over Text::CSV_XS, is that it's pure perl. Also, this is a very minor re-working of Text::CSV_XS - it already does all of these things but with an interface which some find confusing.
[reply]
      The name Text::CSV_XS is a poor name and, IMHO, should be discarded in favor of an XS implementation of Text::xSV called Text::xSV::Fast. It could be included in the distribution and, if a C-compiler exists, should be compiled. Then, at install time, the user can choose if they wish to have the PurePerl version as the primary version or not.

      I never understood the completely artificial separation between Pure-Perl versions and XS versions, not when we have an extensible build system that can require input from the installing user.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
        I didn't choose the name, but I agree. I'm certainly not going to do away with Text::CSV_XS since, as I said it has many users, is included e.g. in many linux distros, etc. so would cause unpredictable incoveniences to drop the name. But I agree that it would be great to combine the two and I've suggested as much to Tilly previously - we've not done it out of time constraints rather than interest. If you look at Comparison of the parsing features of CSV (and xSV) modules, you'll see that Text::CSV_XS has several parsing options that Text::xSV does not (mostly things not needed in ordinary CSV parsing but quite useful for odd legacy formats) so the two modules have other differences than the perl/C differences. I think Text::xSV::Fast might be a good idea, why don't you write it? It could simply subclass Text::CSV_XS and provide some wrappers to implement the Text::xSV interface.
[reply]
        I never understood the completely artificial separation between Pure-Perl versions and XS versions, not when we have an extensible build system that can require input from the installing user.

        Surely at some point in time, you must have seen posts that say "I can't use a module because...". The most common reason quoted is lack of privileges for installing modules, the lack of tools, or lack of the necessary skill. In such a case, installing an XS module is next to impossible...

        At least Pure Perl modules don't actually require proper installation, they can be made to work perfectly with just a few manual kludges. In such a case, "installing" a module is in the same realm as doing so for a script.

[reply]

In Section Meditations