view release on metacpan or  search on metacpan

README  view on Meta::CPAN

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

        Great and all, but one drawback is that it currently destroys
        original file's formatting in serialize().

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

        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>