Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • IMHO you should definitely support 5.8, since it's the default Perl on the latest (or recent) versions of many distributions. I'm not sure 5.6 is worth the trouble, but then again, I can't think of anything in 5.8 that's radically new (e.g. given/when, dor).
    • by chromatic (983) on 2008.06.27 14:13 (#63661) Homepage Journal

      I can't think of anything in 5.8 that's radically new (e.g. given/when, dor).

      Working Unicode, more and updated core modules, bugfixes, much better testing....

      • I mean nothing "radically new" in the sense that it makes your module totally unusable on an older Perl without. For example, I recently wanted to try out Parse::Marpa, but the author uses given/when all over the place. This makes it unusable without 5.10, without providing additional functionality (and with a marginal-at-best improvement in readability).

        New core modules? They're on CPAN. "Working" Unicode? Great if you need it (I don't), but the interface hasn't changed, has it? Testsing and bugfix

        • New core modules? They're on CPAN.

          Many are, but at some point CPAN authors really ought to be able to say "I (added a new feature to|fixed a bug in) Perl 5 years ago; I'm finally going to take advantage of it in code."

          Users oughtn't expect to run the new shiny on ancient installations.

          • Yes, and as a module author you can always tell your users to go fuck themselves at any point. I polish and publish some of the code I write because I hope it can also benefit others, and it can hardly do that if it doesn't work with their versions of Perl. It already takes extra time to get from "works for me" to "works for other people (e.g. documentation), and "works on older Perl" is a minor effort compared to this.
        • Unicode support is a deal-breaker as far as I’m concerned. That the interface superficially hasn’t changed doesn’t matter – it didn’t work prior to 5.8. The identical interface means I don’t have to change my code to make it run and fail to work properly on 5.6. Uhm, hooray.

          • No, it means that you don't have to change your code to make it work all the time with ASCII or Latin-1, and a lot (or at least some) of the time with Unicode.
      • Working Unicode is a bonus if you are dealing with XML as I am.

        However in my situation it's the dependency stack that is a pain, while you can install the dependencies over time on an antique system there comes a time when some of the modules just won't install/upgrade any more. This means that on a brand new 5.6.2 installation it's plain impossible to actually install the dependency stack from CPAN, you have to figure out which older versions of some modules will install and install them one at a time manu

        --
        -- "It's not magic, it's work..."
        • If you want access to a 5.6.2 system for testing, drop me an email and I'll send you the details for a guest account I have for authors to get at one of my CPAN-testing systems.
          • As every thanks for the offer but in the end I got two 5.6 era systems up and running. If I do need access to them what ago of OS are they running? My 5.6.x systems are by their nature antique.

            --
            -- "It's not magic, it's work..."
            • Debian 4.0. I could also build it on FreeBSD 6.2 and OS X 10.4 if you need. I believe that all of those are now the last-but-one version.