Acme-CPANModules-Import-CPANRatings-User-perlancar

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        recipes in the cookbook currently don't really entice me to use the
        module. Let's see: <br><br>1) batch file rename: it's much simpler
        to use 'rename' or 'perlmv' utility. Or, it's much shorter to just
        use plain perl like 'for (grep {-f} &lt;*&gt;) { rename $*,
        s/.log$/.txt/r }'. <br><br>2) recursively remove a directory tree:
        it's much shorter to just use 'File::Path::remove*tree()'.
        <br><br>3) increment a counter file: no locking (it's classic 1990's
        counter.cgi race condition all over again). Take a look at, for
        example, The Perl Cookbook chapter 7.11. Or I think one of Randal
        Schwartz's articles. <br><br>As an alternative, one can also take a
        look at Path::Tiny.

    Common::Routine
        Author: PEKINGSAM <https://metacpan.org/author/PEKINGSAM>

        A couple of comments: <br><br>* Some functions like min(), max(),
        etc need not be reinvented because they are already in core module
        List::Util. But I guess the author wants to be able to say
        min([1,2,3]) in addition to min(1,2,3). <br><br>* round() uses
        Number::Format, note that rounding number using this module is
        hundreds of times slower than using sprintf(). <br><br>

    Submodules
        Author: ZARABOZO <https://metacpan.org/author/ZARABOZO>

        A couple of prior arts: <br><br>* all, <a
        href="https://metacpan.org/pod/all"
        rel="nofollow">metacpan.org/pod/all</a> (since 2003), nicer
        interface and offers &quot;use&quot;/compile-time interface, so it's
        more equivalent to the statements it wants to replace. The
        Submodules equivalent would be: BEGIN { for my $i
        (Submodules-&gt;find(&quot;Blah&quot;)) { $i-&gt;require } }.
        <br><br>* Module::Require, <a
        href="https://metacpan.org/pod/Module::Require"
        rel="nofollow">metacpan.org/pod/Module::Require</a> (since 2001),
        also nicer interface, more flexible, and more lightweight
        implementation. <br><br>I don't like Submodules' interface, it's too
        verbose and clunky. IMO, the interface should be a one-liner and
        without manual looping.

    Regexp::Assemble
        Author: RSAVAGE <https://metacpan.org/author/RSAVAGE>

        I guess it depends on your data, but for random shortish strings
        (hundreds to thousands of them), I find that using raw joining is
        much faster to assemble the regex. And the resulting regex is also
        (much) faster to match. Please see Bencher::Scenario::RegexpAssemble
        if you're interested in the benchmark script.

    Tie::Scalar::Callback
        Author: DFARRELL <https://metacpan.org/author/DFARRELL>

        There is a prior art Tie::Simple (created in 2004) which works for
        scalar as well as the other types of ties that perl supports (array,
        hash, handle). <br>

    JSON::Create
        Author: BKB <https://metacpan.org/author/BKB>

        Review for 0.02: Performance-wise, still has some catching up to do
        against JSON::XS &amp; Cpanel::JSON::XS with regards to encoding
        arrays &amp; hashes. <br><br>UPDATE review for 0.19: Giving it 4
        stars now. Speed has been improving and on-par/slightly better than
        the other JSON XS modules in some areas, while a bit worse in some
        other areas. Faster modules are always welcome.

        Rating: 8/10

    Set::Scalar
        Author: DAVIDO <https://metacpan.org/author/DAVIDO>

        Confirming previous reviewer, the module is a lot slower (~ 20-40x)
        than other alternatives like Array::Utils or List::MoreUtils when
        you want to perform basic set operations like
        union/intersect/diff/symmetric diff.

    Exporter::Easy
        Author: NEILB <https://metacpan.org/author/NEILB>

        I can see the value of Exporter::Easy (although these days the
        saving in typing is not as big, with plain Exporter one can just
        say: use Exporter 'import'; our @EXPORT = qw(a b c)).
        <br><br>However I fail to see the value of Exporter::Easiest. I'd
        rather use plain Perl than some DDL which cannot be checked
        statically or cannot be syntax-highlighted, just to save some []'s
        and ()'s (which I can get my editor to help me type them).
        <br><br>In short, I'd rather use plain Exporter than save a few
        keystrokes but add a non-core dependency.

        Rating: 6/10

    App::cpm
        Author: SKAJI <https://metacpan.org/author/SKAJI>

        Due to parallel processes and defaulting on no_test, can be several
        times faster than cpanminus (tried installing a module on a vanilla
        perlbrew instance with local CPAN mirror, which pulled +- 200
        distributions, &quot;cpanm -n&quot; took 2m9s, while cpm took 38s.)
        I hope this gets developed further. Great job. <br>

    Zodiac::Chinese
        Author: CAVAC <https://metacpan.org/author/CAVAC>

        From the doc: &quot;This module generates one's Chinese zodiac.
        However, for those born in late January to early February, it may be
        wrong.&quot; Well, a module that might return wrong results is not
        very useful. <br>

        Rating: 2/10

    JSON::MultiValueOrdered
        Author: TOBYINK <https://metacpan.org/author/TOBYINK>

        I guess if you want to switch JSON implementation more easily with
        JSON, JSON::PP, and JSON::XS, it's better to use
        JSON::Tiny::Subclassable instead of JSON::Tiny, because the
        interface is more similar to JSON{::XS,::PP}, although it's not
        exactly the same. JT:Subclassable also supports pretty() which is
        often used when debugging. In short, I found
        JSON::Tiny::Subclassable is a better &quot;Tiny JSON&quot; module
        than JSON::Tiny.

README  view on Meta::CPAN

    Log::Declare
        Author: CHGOVUK <https://metacpan.org/author/CHGOVUK>

        I haven't used or evaluated this module in detail, but if there is
        one advantage to using procedural/command syntax: <br><br>info blah;
        <br><br>as opposed to object syntax: <br><br>$log-&gt;info(blah);
        <br><br>then this module clearly demonstrates it. Using
        Devel::Declare (or the Perl 5.14+ keyword API), the former can be
        easily rewritten as something like: <br><br>info &amp;&amp; blah;
        <br><br>or: <br><br>if (CONST_LOG_INFO) { info blah } <br><br>and
        during compilation, Perl can optimize the line away and we get zero
        run-time penalty when logging (level) is disabled.
        <br><br>(Actually, it's also possible for the object syntax to get
        rewritten, e.g. using source filter, but it's more cumbersome).

    Benchmark::Timer
        Author: DCOPPIT <https://metacpan.org/author/DCOPPIT>

        Nice alternative module for benchmarking with a different interface
        than Benchmark (marking portion of code to be benchmarked with start
        and stop). <br><br>For most Perl programmers familiar to the core
        module Benchmark, I recommend looking at Benchmark::Dumb first
        though. It has an interface like Benchmark (cmpthese() et all) but
        with some statistical confidence.

    Getargs::Long
        Author: DCOPPIT <https://metacpan.org/author/DCOPPIT>

        Nice idea, but some performance concerns. If you want to use
        cgetargs (the compiled, faster version), you are restricted to the
        getargs() interface, which only features checking for required
        arguments and supplying default value. In which case you might as
        well use Params::Validate directly as it's several times (e.g. 3-4x)
        faster. <br><br>If you want to use the more featured xgetargs, there
        is currently no compiled version. <br><br>All in all, I think users
        should take a look at Params::Validate first.

    Debug::Easy
        Author: RKELSCH <https://metacpan.org/author/RKELSCH>

        Not as easy as the name might claim. First of all, why do users need
        to pass LINE explicitly for every call??? Other logging modules will
        get this information automatically via caller(). <br><br>Levels are
        a bit confusing: why is debug split to 2 (or 3)? <br><br>Not as
        flexible as it should be because the design conflates some things
        together. For example, most levels output to STDERR but some level
        (VERBOSE) outputs to STDOUT instead. The output concern and levels
        should've been separated. Another example would be the DEBUGWAIT
        level, where level is DEBUG *and* execution is halted (wait on a
        keypress) on log. What if users want a lower level setting *but*
        want execution to be halted on log? The halt/keypress setting
        should've been separated from the level.

        Rating: 4/10

    File::Slurper
        Author: LEONT <https://metacpan.org/author/LEONT>

        Who'da thought that something as seemingly simple as &quot;slurping
        a file into a string&quot; would need several modules and false
        starts? Well, if you add encodings, Perl I/O layers, scalar/list
        context, DWIM-ness, ... it can get complex and buggy. I'm glad there
        are people taking care of this and making sure that a simple task
        stays simple and correct.

    File::Slurp
        Author: CAPOEIRAB <https://metacpan.org/author/CAPOEIRAB>

        Use the newer File::Slurper instead, which has a clearer API (e.g.
        text vs binary, array/lines vs string) and encoding default. It's
        arguably &quot;saner&quot; than File::Slurp and File::Slurp::Tiny.
        <br>

    File::Slurp::Tiny
        Author: LEONT <https://metacpan.org/author/LEONT>

        Use the newer File::Slurper instead, which has a clearer API (e.g.
        text vs binary, array/lines vs string) and encoding default. It's
        arguably &quot;saner&quot; than File::Slurp and File::Slurp::Tiny.
        <br>

    Perl::PrereqScanner::Lite
        Author: MOZNION <https://metacpan.org/author/MOZNION>

        A significantly faster alternative to Perl::PrereqScanner. It's
        *almost* a drop-in replacement, there might still be some bugs in
        missing detecting some modules, and you still have to do several
        add_extra_scanner() calls like
        $scanner-&gt;add_extra_scanner('Moose') to match the behavior of
        Perl::PrereqScanner. <br><br>

    Logfile::Rotate
        Author: PAULG <https://metacpan.org/author/PAULG>

        First file rotating module I found and tried. Works, but needs to be
        modernized a bit. Indirect object notation in doc should be
        replaced. Bool option takes &quot;yes&quot; or &quot;no&quot;,
        should perhaps be 1 or 0. Capitalization adjustment, perhaps.
        <br><br>

        Rating: 6/10

    File::ReadBackwards
        Author: PLICEASE <https://metacpan.org/author/PLICEASE>

        At the time of this review, I find two modules for reading a file
        backwards: File::Bidirectional (FBidi) and File::ReadBackwards
        (FRB). <br><br>Both modules have roughly the same footprint and
        minimal dependencies. Both provide OO as well as tie interface. Both
        respect the $/ setting. <br><br>FRB pro's: <br> - FRB is 15-20%
        faster than FBidi when reading backwards; <br><br>FRB con's: <br> -
        does not offer the feature of reading forward as well, but of course
        this is not the goal of the module. <br><br>FBidi's POD contains
        information on benchmarks (it's roughly an order of magnitude slower
        than raw Perl's open+read/diamond operator, still the case in 2014).
        While FRB's POD contains information on how the thing works behind
        the scenes. <br><br>In summary, both modules are roughly the same.
        I'd prefer FRB unless in the rarer cases where I need bidirectional
        reading. <br>

        Rating: 8/10

    File::Bidirectional
        Author: KIANWIN <https://metacpan.org/author/KIANWIN>

        At the time of this review, I find two modules for reading a file
        backwards: File::Bidirectional (FBidi) and File::ReadBackwards
        (FRB). <br><br>Both modules have roughly the same footprint and
        minimal dependencies. Both provide OO as well as tie interface. Both
        respect the $/ setting. <br><br>FBidi pro's: <br> - has the unique
        feature of reading backward/forward and switch direction in the
        middle; <br><br>FBidi con's: <br> - FBidi is 15-20% slower than
        FBidi when reading backwards; <br> - reading forward is just as slow
        as backward, so if you only need to read forward, obviously there's
        no need to use this module; <br><br>FBidi's POD contains information
        on benchmarks (it's roughly an order of magnitude slower than raw
        Perl's open+read/diamond operator, still the case in 2014). While
        FRB's POD contains information on how the thing works behind the



( run in 1.970 second using v1.01-cache-2.11-cpan-39bf76dae61 )