view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        Any module from ADAMK should be interesting, including this one. But
        please take a look at CPAN::Changes for the de facto standard
        nowadays.

    Module::Metadata::Changes
        Author: RSAVAGE <https://metacpan.org/author/RSAVAGE>

        Like Module::Changes, this module also tries to use a more defined
        format for Changes. Sadly, it has not caught on. Please also take a
        look at CPAN::Changes which seems to be the de facto standard
        nowadays.

    Module::Changes
        Author: MARCEL <https://metacpan.org/author/MARCEL>

        In general I'm not opposed to the idea of this module. The included
        'changes' script is also pretty cool (which I'm trying to recreate,
        for CPAN::Changes). <br><br>Just pointing out that I believe this
        module has not really &quot;caught on&quot; among the CPAN
        community. What has, is, CPAN::Changes which is followed by many
        authors and even employed on MetaCPAN. <br>

    Archive::Tar::Wrapper
        Author: ARFREITAS <https://metacpan.org/author/ARFREITAS>

        Sadly there is not a single perfect Archive::Tar::* module out
        there. Either a module offers incomplete API, (was) buggy, or it is
        crippled/limited in some way. Plus, the modules are mostly
        incompatible with one another. And that's why TIMTOWTDI. <br><br>For
        the task of just listing files in an archive, for example, it seems
        only Archive::Tar and Archive::Tar::Wrapper are usable.
        Archive::Tar::Wrapper is fast (because it utilizes external C-based
        tar utility) and does not load all contents of an archive into
        memory, but requires writing to temporary files and of course
        requires a tar utility so portability to non-Unix systems might be
        an issue.

    Archive::Tar
        Author: BINGOS <https://metacpan.org/author/BINGOS>

        Sadly there is not a single perfect Archive::Tar::* module out
        there. Either a module offers incomplete API, (was) buggy, or it is
        crippled/limited in some way. Plus, the modules are mostly
        incompatible with one another. And that's why TIMTOWTDI. <br><br>For
        the task of just listing files in an archive, for example, it seems
        only Archive::Tar and Archive::Tar::Wrapper are usable. Archive::Tar
        is a core module, but relatively slow, and extracts all contents of
        an archive in memory so it's not workable for huge archives. <br>

    Hash::Util::Pick
        Author: PINE <https://metacpan.org/author/PINE>

        One can easily use this idiom instead: <br><br>$picked = { map
        {(exists $hash{$*} ? ($*=&gt;$hash{$*}):())} @keys }; <br><br>or:
        <br><br>$picked = { map {$*=&gt;$hash{$*}} grep {exists $hash{$*}}
        @keys }; <br><br>or (if you want non-existing picked keys to be
        created instead): <br><br>$picked = { map {$_ =&gt; $hash{$_}} @keys
        }; <br><br>but Hash::Util::Pick is implemented in XS and can be a
        few times faster than the above when the number of keys has reached
        thousands. So I guess this module has its uses.

    NetObj::IPv4Address
        Author: HEEB <https://metacpan.org/author/HEEB>

        Cons: more heavyweight (requires Moo), limited operations/methods,
        can only handle IPv4 and not IPv6. Pros: some operations are faster
        than competing modules, e.g. validation. See also: NetAddr::IP,
        Net::CIDR. <br>

    NetObj::MacAddress
        Author: HEEB <https://metacpan.org/author/HEEB>

        Aside from being Moo-based (which, makes it a bit more heavyweight
        and with more dependencies), doesn't yet offer anything extra or
        more methods compared to previously existing modules like
        NetAddr::MAC.

        Rating: 4/10

    Acme::AsciiArtinator
        Author: MOB <https://metacpan.org/author/MOB>

        Cool. Now you can create your own Camel Code with ease!

    Object::Simple
        Author: KIMOTO <https://metacpan.org/author/KIMOTO>

        I'd say in terms of footprint and runtime performance, this module
        is average (it's not the most lightweight nor the fastest pure-perl
        object system, not to mention against XS ones). See my
        Bencher::Scenarios::Accessors for a comparison, e.g. <a
        href="https://metacpan.org/pod/Bencher::Scenario::Accessors::Get"
        rel="nofollow">metacpan.org/pod/Bencher::Scenario::A...</a> and <a
        href="https://metacpan.org/pod/Bencher::Scenario::Accessors::Set"
        rel="nofollow">metacpan.org/pod/Bencher::Scenario::A...</a> .
        <br><br>One drawback of using Mojo::Base and Object::Simple is its
        similar but slightly different and incompatible syntax with the Moo*
        family, so your code is not &quot;upgradable&quot; to Moo or Moose
        once you need more features. And often you'll end up wanting them,
        e.g. one day you'll probably read about the wonders of method
        modifiers (before, after, around), or roles, or wanting to have a
        lazy constructor, or triggers, and so on. <br><br>I'd recommend
        instead Mo. It's more lightweight than Object::Simple and you can do
        default value, builder, ro/rw, required, even coercion. But the
        features are modular and you only pay for what you use. And once you
        need more features later, you normally should be able to just
        replace 'use Mo' in your code with 'use Moo' or 'use Moose'.
        <br><br>Of course, this point is moot if you don't care about
        compatibility/upgradability to Moo*.

        Rating: 6/10

    Test::Needs
        Author: HAARG <https://metacpan.org/author/HAARG>

        Nice. API is more convenient to use than Test::Requires, especially
        if you use subtests. <br>

    HTTP::Command::Wrapper
        Author: PINE <https://metacpan.org/author/PINE>

        There are a few use-cases where this would be useful (mostly, to
        access https websites in the absence of required perl library like
        LWP::Protocol::https), but it would be more useful to provide an API
        that is already familiar to Perl programmers. That's why MIYAGAWA
        created HTTP::Tinyish.

    File::Util
        Author: TOMMY <https://metacpan.org/author/TOMMY>

        Point for documentation (lots of examples and cookbook). But the
        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.

    JSON::Tiny
        Author: DAVIDO <https://metacpan.org/author/DAVIDO>

        Ah, the many JSON implementation modules out there... <br><br>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. <br><br>

    Devel::Confess
        Author: HAARG <https://metacpan.org/author/HAARG>

        Provides some more features compared to Carp::Always, like producing
        stack trace even when exception is ref/object, color &amp; dump
        function arguments (so you don't need a separate Carp::Always::Dump
        and Carp::Always::Color). Recommended. <br>

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

        This module works well for string exceptions (e.g. die &quot;some
        message&quot;), but for ref/object exceptions (e.g. die
        [404,&quot;Not found&quot;] or die $some_object) it will simply
        print/return the ref/object and thus no stack trace information is
        produced. <br><br>See also Devel::Confess, which can handle
        ref/object. <br><br>References: <br> <a
        href="http://blogs.perl.org/users/graham_knop/2013/09/carp-always-ev
        enobjects.html"
        rel="nofollow">blogs.perl.org/users/graham_knop/2013...</a>

    experimental
        Author: LEONT <https://metacpan.org/author/LEONT>

        Our prayer has been answered. experimental was added to perl core in
        5.19.11

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

        Mostly unnecessary. The main premise of this module is that you
        don't need to inherit to use it. But you also can use Exporter (a
        core module, BTW) without inherinting it: <br><br>use Exporter
        qw(import); <br>

    Date::Holidays
        Author: JONASBN <https://metacpan.org/author/JONASBN>

        The idea is good, but a couple of things prevents me from using this
        interface. <br><br>First, the use of TryCatch (which brings the
        Moose ecosystem) makes the startup overhead too high for my taste
        (about 0.5s on my PC). Which is rather unfortunate because
        Date::Holidays itself does not use Moose. <br><br>Second, the
        interface assumes that a country has a single set of holidays, which
        is too restrictive in some cases. A more flexible/general interface
        would allow adding more calendars based not only on country but also
        religion, special community, organization, etc. And allow adding
        custom calendars. <br>

    Furl
        Author: SYOHEX <https://metacpan.org/author/SYOHEX>

        @Kira S (I wish cpanratings adds a feature to comment on a review):
        <br><br>Comparing WWW::Mechanize with Furl is not really
        apples-to-apples, since Furl does not support parsing/following

README  view on Meta::CPAN

        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
        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

    Signal::StackTrace::CarpLike
        Author: SARTAK <https://metacpan.org/author/SARTAK>

        Nice, but Signal::StackTrace should've output something carp-like in
        the first place.

    Devel::Messenger
        Author: KOLIBRIE <https://metacpan.org/author/KOLIBRIE>

        I think this is basically logging under a fancy name and with a more
        cumbersome interface. Look at Log::Any instead.

    Term::Twiddle
        Author: SCOTTW <https://metacpan.org/author/SCOTTW>

        Cute! I didn't know SIGALRM still works even though you're doing
        blocking I/O or calling other programs. But unfortunately it doesn't
        work if you sleep(), making this approach not as attractive. <br>

    CHI Author: ASB <https://metacpan.org/author/ASB>

        The move to Moo is very welcome, but I wish there were an
        alternative of CHI which is even more lightweight (starts in under
        0.01s). CHI::Tiny, anyone?

    App::YTDL
        Bit of a shame that we currently don't have a working YouTube
        download script/module (WWW::YouTube::Download is last updated 2013
        and has been broken for a long while). This module actually requires
        another *Python* script to do its job. I might as well skip this and
        go straight to the Python script. <br><br>UPDATE 2016-03-04: I guess
        it's been so for a few years, but this still needs to be said: For
        downloading YouTube videos, use youtube-dl (a far more popular
        Python project) and just forget the rest. Keeping up with YouTube
        changes is many times a full time job. Nothing else comes remotely
        close.

    XXX Author: INGY <https://metacpan.org/author/INGY>

        The part that makes this module convenient is that the functions
        return their original arguments. So when debugging (peppering dump
        statements), you don't have to change this: <br><br>return
        [&quot;some&quot;, $expr]; <br><br>to this (taking an example from
        another dumping module, Data::Dump): <br><br>my $tmp =
        [&quot;some&quot;, $expr]; dd $tmp; return $tmp; <br><br>but just
        this: <br><br>return YYY [&quot;some&quot;, $expr]; <br><br>This
        should be imitated by the other dumper functions.

FAQ
  What is an Acme::CPANModules::* module?
    An Acme::CPANModules::* module, like this module, contains just a list
    of module names that share a common characteristics. It is a way to
    categorize modules and document CPAN. See Acme::CPANModules for more
    details.

  What are ways to use this Acme::CPANModules module?
    Aside from reading this Acme::CPANModules module's POD documentation,
    you can install all the listed modules (entries) using cpanm-cpanmodules
    script (from App::cpanm::cpanmodules distribution):

     % cpanm-cpanmodules -n Import::CPANRatings::User::perlancar

    Alternatively you can use the cpanmodules CLI (from App::cpanmodules
    distribution):

        % cpanmodules ls-entries Import::CPANRatings::User::perlancar | cpanm -n

    or Acme::CM::Get:

        % perl -MAcme::CM::Get=Import::CPANRatings::User::perlancar -E'say $_->{module} for @{ $LIST->{entries} }' | cpanm -n

    or directly:

        % perl -MAcme::CPANModules::Import::CPANRatings::User::perlancar -E'say $_->{module} for @{ $Acme::CPANModules::Import::CPANRatings::User::perlancar::LIST->{entries} }' | cpanm -n

    This Acme::CPANModules module also helps lcpan produce a more meaningful
    result for "lcpan related-mods" command when it comes to finding related
    modules for the modules listed in this Acme::CPANModules module. See
    App::lcpan::Cmd::related_mods for more details on how "related modules"
    are found.

HOMEPAGE
    Please visit the project's homepage at
    <https://metacpan.org/release/Acme-CPANModules-Import-CPANRatings-User-p
    erlancar>.

SOURCE
    Source repository is at
    <https://github.com/perlancar/perl-Acme-CPANModules-Import-CPANRatings-U
    ser-perlancar>.