view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    Parse::RecDescent
        Author: JTBRAUN <https://metacpan.org/author/JTBRAUN>

        Responding to previous comment from MB: &quot;Have you the time to
        do this Damian?&quot; The answer is yes, in the form of
        Regexp::Grammars, which Damian said himself is the successor of
        Parse::RecDescent. <br><br>To give credit to this module, PRD is
        very featureful and easy to use, it's very convenient to generate
        parsers, and the docs is quite complete. The only problem with it
        is, as many have pointed out, speed. <br><br>It is *seriously* slow,
        with parser generation can take up to half a second on my laptop
        with a moderate grammar (200-400 lines) and parsing can take seconds
        even minutes for a moderately long string. It is orders of magnitude
        slower than other parsers. Do think a few times before deciding you
        can take the performance hit of PRD. <br><br>For alternatives, try
        Regexp::Grammars. (Or Parse::Yapp or Parse::EYapp, as other
        reviewers have written.)

        Rating: 6/10

    Test::Seperate
        Sorry, just commenting the name, shouldn't it be Separate?

    File::Size
        Author: OFER <https://metacpan.org/author/OFER>

        Frankly I prefer the name and interface of Filesys::DiskUsage.
        Sadly, despite the docs mentioning &quot;blocks&quot;, this module
        doesn't really count block usage like the Unix &quot;du&quot;
        command, because it doesn't take multiple hard links into account.
        <br><br>Even more sadly, Filesys::DiskUsage doesn't either.
        <br><br>I guess I'll have to do with 'system &quot;du $file&quot;'
        command for now. <br>

        Rating: 4/10

    DateTime
        Author: DROLSKY <https://metacpan.org/author/DROLSKY>

        *THE* definitive date/time handling module in Perl (and even maybe
        in all major programming languages). Can't believe I went through
        all the pain of reinventing the wheel, and using various date/time
        modules of various quality &amp; interface. If only I had known
        DateTime earlier. <br><br>Look no more, DateTime it is. <br>

    Data::Rx
        Author: RJBS <https://metacpan.org/author/RJBS>

        I've been mulling over writing this kind of module (planning to call
        it Schema::Nested or something), but never got around to do it.
        Thankfully somebody stepped up and did it! Keep up the good work,
        will be looking forward to future releases (especially i'm hoping
        for some subclassing mechanism, for better reuse of schemas). <br>

    DBI::Mysqlsimple
        I agree with the previous reviewer. IMO, overall this module is not
        necessary. Plain DBI is actually simple enough for simple cases.
        Maybe the author of Mysqlsimple did not realize this. Let's compare:
        <br><br>* Retrieving a single row: <br> Mysqlsimple: my ($v1,$v2) =
        $db-&gt;get_row(&quot;select v1,v2 from table&quot;); <br> DBI: my
        ($v1, $v2) = $dbh-&gt;selectrow_array(&quot;select v1,v2 from
        table&quot;); <br><br>* Retrieving a single row (with params): <br>
        Mysqlsimple: my ($v1,$v2) = $db-&gt;get_row(&quot;select v1,v2 from
        table where cond1=? and cond2=?&quot;, [$cond1,$cond2]); <br> DBI:
        my ($v1,$v2) = $db-&gt;selectrow_array(&quot;select v1,v2 from table
        where cond1=? and cond2=?&quot;, {}, $cond1,$cond2); <br><br>*
        Retrieving all rows with params: <br> Mysqlsimple: my $rows =
        $db-&gt;get_rows(..., [$param1, $param2]); <br> DBI: my $rows =
        $dbh-&gt;selectall_arrayref(..., {}, $param1, $param2); <br><br>*
        do() with params: <br> Mysqlsimple: my $rows = $db-&gt;do(...,
        [$param1, $param2]); <br> DBI: my $rows = $dbh-&gt;do(..., {},
        $param1, $param2); <br><br>As you can see, the differences are
        minimal. <br>

        Rating: 2/10

    Carp::Always
        Author: FERREIRA <https://metacpan.org/author/FERREIRA>

        Modules like this deserve to be more well-known and should perhaps
        included in core Perl (or even become a command-line switch). I'm
        never comfortable with Carp and all the &quot;complexity&quot; of
        using it. What I wanted is simple, when debugging I want all die()'s
        (and perhaps warn() too, but much less often) to print a stack
        trace. <br><br>Call me inflicted with Ruby- or Python-envy, but it's
        been so ridiculous wanting to print out stack traces in Perl. I
        don't want to have to change/rewrite all my die()'s to croak() or
        confess()! And what about library codes which use die()?
        <br><br>Thank God somebody wrote Carp::Always.

    Data::Dump
        Author: GARU <https://metacpan.org/author/GARU>

        I've envied Ruby users which can use just &quot;p&quot; to print out
        data structures instead of us which used to have to do 'use
        Data::Dumper; print Dumper(...);'. And even then there's this '$VAR1
        = ' garbage which 99% of the time is not wanted. Which often makes
        me wonder, shouldn't P in Perl stand for Practical? <br><br>With
        Data::Dump we're still a bit behind but closer. One rant is the with
        the doc: the pp() function should perhaps be advertised more
        prominently, since I suspect that's what most users want most of the
        time.

    V   Author: ABELTJE <https://metacpan.org/author/ABELTJE>

        What a nice little module. It is by far the easiest to review ;-)
        <br><br>I have been using my own little script called
        &quot;pmversion&quot; which serves the same exact purpose. I guess
        I'll be using V from this moment on. It's amazing doing something as
        basic as showing a module's version had not been this easy or even
        easier. <br>

    Test::Unit
        Author: MCAST <https://metacpan.org/author/MCAST>

        Test::Unit is of course a fine module. But if you are shopping
        around for testing framework, I recommend you try Test::Class
        instead, which combines the best of two worlds. First, you get xUnit
        style, but I think with a slightly simpler interface. Second, you
        get to use all the standard Perl testing stuffs like Test::Simple,
        Test::More and Test::Harness. This is better because it's what most
        Perl modules use (so you might be more familiar with it if you're a
        Perl programmer), plus there are more kinds of &quot;assert&quot;
        functions in Test::More and friends compared to Test::Unit::Assert.

        Rating: 8/10

    Module::Build
        Author: LEONT <https://metacpan.org/author/LEONT>