Acme-CPANModules-Import-CPANRatings-User-perlancar

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        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>

README  view on Meta::CPAN

        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
        links or form processing. As the Furl POD itself suggests, Furl is
        positioned as a faster alternative to LWP, not WWW::Mechanize.

    Lingua::EN::Inflect
        Author: DCONWAY <https://metacpan.org/author/DCONWAY>

        Just add this review to link to Ben Bullock's
        Lingua::EN::PluralToSingular if you need to go the other way
        (converting English noun from plural to singular). <br><br>BTW, I
        don't like the interface either, and wonder why the Env module needs
        to be involved. <br>

    Lingua::EN::PluralToSingular
        Author: BKB <https://metacpan.org/author/BKB>

        Not perfect or exhaustive, but good enough and lightweight. With a
        dead-simple interface. Just the sort of libraries that are reusable
        almost everywhere. Thanks for this. <br><br>Also, this might not be
        immediately obvious since there's no mention on the See Also
        section: to go the other way (converting English noun from singular
        to plural) you can use Lingua::EN::Inflect.

    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>

README  view on Meta::CPAN

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

SEE ALSO
    Acme::CPANModules - about the Acme::CPANModules namespace

    cpanmodules - CLI tool to let you browse/view the lists

AUTHOR
    perlancar <perlancar@cpan.org>

CONTRIBUTING
    To contribute, you can send patches by email/via RT, or send pull
    requests on GitHub.

    Most of the time, you don't need to build the distribution yourself. You
    can simply modify the code, then test via:

     % prove -l

    If you want to build the distribution (e.g. to try to install it locally
    on your system), you can install Dist::Zilla,
    Dist::Zilla::PluginBundle::Author::PERLANCAR,
    Pod::Weaver::PluginBundle::Author::PERLANCAR, and sometimes one or two
    other Dist::Zilla- and/or Pod::Weaver plugins. Any additional steps
    required beyond that are considered a bug and can be reported to me.

COPYRIGHT AND LICENSE
    This software is copyright (c) 2023, 2018 by perlancar
    <perlancar@cpan.org>.

    This is free software; you can redistribute it and/or modify it under
    the same terms as the Perl 5 programming language system itself.

BUGS
    Please report any bugs or feature requests on the bugtracker website
    <https://rt.cpan.org/Public/Dist/Display.html?Name=Acme-CPANModules-Impo
    rt-CPANRatings-User-perlancar>

    When submitting a bug or request, please include a test-file or a patch
    to an existing test-file that illustrates the bug or desired feature.