view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        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